"Terminal Command" issues

Ok, I have a workaround that "works for me", even if it's not really what I would like to have.

I'm now encoding my script as BASE64 and do something like this:

base64 -d > /tmp/somefilename <<'SCRIPTROLLOUTEOT'
BASE64ENCODEDSCRIPT
SCRIPTROLLOUTEOT
chmod o+r /tmp/somefilename
# Code that copies the decoded script-file to all required destinations
rm -f /tmp/somefilename

What I would have liked to do was basically the same, but

• without the extra steps to manually encode the script to BASE64 (and of course the decoding in this snippet)
• Without the need to change the actual script code in the "Run"-field
  • This introduces the risk of changing not only the line with the script code
  • This in turn introduces the risk of destructive errors in the rollout-snippet each time the script content must be updated
  • This issue could be prevented if the script content could just be put into CUSTOM_FIELD5 (for example), which is currently not possible because the custom field variables do not seem to be substituted when sending the "Run"-filed contents (even though the "{HOME}" string is replaced)

Hello,

Thank you for your message, and please accept my apologies for the delayed response.

I have tested this on my end and can confirm your findings regarding the custom fields. I was unable to locate any documentation indicating that this behavior is unsupported, so I will report this as a bug to our development team for further investigation and resolution.

Based on your note that resolving the custom field issue would address the overall problem, I will pause further investigation for now. Please let me know if there is anything else you would like me to verify. Otherwise, I will follow up with an update once a fix has been implemented in a future release.

Best regards,

Well, in my case (though, since we are talking about the "Terminal Command" entry type, which is designed to execute shell scripts, I would have expected this to be the common case) this would only be a "complete" solution, if the "makro"-placeholders (like "{HOME}") will not be substituted in content inserted from (e.g.) CUSTOM_FIELD5. Since then this would, once again, replace "${HOME}" (the shell variable) with "$" followed by a HOME-key code.

But yes, since this would allow updating the script by only replacing the script-part in the Custom Field 5 edit-field, and leaving the actual rollout-script untouched, this would be a tremendous help.

Hello,

Thank you for your patience.

The development team has confirmed that custom fields and their variables are not supported in the Terminal command entry type. For future needs, I would recommend submitting a feature request on this matter.

Regarding the use of {HOME}, $HOME, and ${HOME}, I ran a few tests and observed the following behavior:

echo {HOME}: does not resolve and returns "{HOME}" as-is.
echo $HOME: resolves correctly and displays the home directory path (e.g., "/home/jacob").
echo ${HOME}: does not resolve, because empty and returns only "$".

As I do not frequently work with scripting, I want to ensure we are aligned on the expected behavior. Please let me know what results you are seeing on your side.

If possible, could you also share the relevant portion of your script or confirm whether you are encountering similar behavior? I would be happy to investigate further.

Best regards,

Hi Jacob,

I'm sometimes patient, having a workaround helps. ;)

It's unfortunate, that the dev-teams seems to see "not using custom fields as substitution values" as a design choice. Maybe I'll submit a feature request. We'll see.

Regarding your tests, I'm not sure if you tested "correctly". I had reproducibly the following effects.

The script I want to execute might look like this:

if [[ -f "${HOME}/.ssh/authorized_keys" ]]
then
  echo "file exists"
fi

but what then is actually visible in the terminal is this:

/.ssh/authorized_keys" ]]if [[ -f "$
then
  echo "file exists"
fi

like in this example

Last login: Fri Apr 17 11:30:42 CEST 2026
Last login: Fri Apr 17 11:33:04 2026 from 62.96.121.163
[opc@dbnode1 ~]$ /.ssh/authorizedkeys" ]]if [[ -f "$
-bash: /.ssh/authorizedkeys ]]if [[ -f $: No such file or directory
[opc@dbnode1  ~]$
[opc@dbnode1  ~]$ then
-bash: syntax error near unexpected token `then'
[opc@dbnode1  ~]$
[opc@dbnode1  ~]$   echo "file exists"
file exists
[opc@dbnode1  ~]$
[opc@dbnode1  ~]$ fi
-bash: syntax error near unexpected token `fi'
[opc@dbnode1  ~]$

If I write the script like this

echo {HOME}
echo $HOME
echo ${HOME}
echo "${HOME}"

then the result after execution will look like this

[opc@dbnode1 ~]$ echo

[opc@dbnode1 ~]$ echo $HOME
/home/opc
[opc@dbnode1 ~]$ echo $
$
[opc@dbnode1 ~]$ "echo "$
-bash: echo $: command not found

Hello,

Thank you for your follow-up.

I was able to reproduce the issue. I observed different results when running a simple script compared to executing the same commands directly in the terminal.

Script:

echo {HOME}
echo $HOME
echo ${HOME}
echo "${HOME}"

Output when run via script:

david@VUBUGUI:~$ echo

david@VUBUGUI:~$
david@VUBUGUI:~$ echo $HOME
/home/david
david@VUBUGUI:~$
david@VUBUGUI:~$ echo $
$
david@VUBUGUI:~$
david@VUBUGUI:~$ "echo "$
echo $: command not found

Output when executed directly in the terminal:

david@VUBUGUI:~$ echo {HOME}
{HOME}
david@VUBUGUI:~$ echo $HOME
/home/david
david@VUBUGUI:~$ echo ${HOME}
/home/david
david@VUBUGUI:~$ echo "${HOME}"
/home/david

I will report this issue to our development team and will keep you informed once a fix is available in a future release.

Thank you for your patience and understanding.

Best regards,