Inconsistent Behavior with Variable Substitution

[terrabytecubed]

Hi bugy,

I encountered something interesting in using script-server regarding variable substitution. In this excerpt from the config I wrote, I found that the first parameter correctly substituted the environment variable $ENV_VAR_TO_PATH whereas the second parameter produced an error whereby it was trying to parse ${ENV_VAR_TO_PATH} as an injected parameter despite shell being set to true.

"parameters": [
        {
            "name": "First",
            "param": "--first",
            "required": true,
            "constant": true,
            "default": { "script": "echo ${ENV_VAR_TO_PATH}/path", "shell": true }
        },
        {
            "name": "Second",
            "required": false,
            "description": "Second, non constant parameter.",
            "type": "list",
            "values": { "script": "ls -1 -- ${ENV_VAR_TO_PATH}/path", "shell": true }
        }
    ],

I was able to discover the following work around, whereby I omitted the curly brace.

"parameters": [
        {
            "name": "First",
            "param": "--first",
            "required": true,
            "constant": true,
            "default": { "script": "echo ${ENV_VAR_TO_PATH}/path", "shell": true }
        },
        {
            "name": "Second",
            "required": false,
            "description": "Second, non constant parameter.",
            "type": "list",
            "values": { "script": "ls -1 -- $ENV_VAR_TO_PATH/path", "shell": true }
        }
    ],

I suspect that this might have to do with the code to detect injected parameters in non-shell mode where the token ${ is explicitly checked for. It's by no means a life ending bug, but I figured you might like this brought to your attention :)

[bugy]

Hi @terrabytecubed thanks for reporting, looks really weird. Glad you found a workaround. I'll try to have a look here

[bugy]

Hi @terrabytecubed I tried to fix it, but it turned out to be quite complicated. Script server validates, that every time you use a dynamic parameter (e.g. referencing parameter1 from parameter2 script like: "script": "echo ${parameter1}"), this parameter exists in configuration For whatever reason, this validation is not there for "default" section, that's why you don't see an error there. I would call it a bug.

Long story short: this can be fixed, but the solution is not straightforward, so I won't include it as a quickfix for the release