may be we could pass parameter to script by name

[yosefy]

because when there are too many it becomes pretty complicated to remember numbers

may be there is such an option?

(i can live without it... just a thought)
thanks

[bugy]

Hi @yosefy could you explain in examples, please, what do you mean?
I'm not sure which numbers you are talking about

[yosefy]

there is a name for each parameter

{
  "name": "choose_environment",
  "param": "--env",
  "description": "Environment",
  "required": true,
  "type": "list",
  "default": "dev",
  "values": [
    "dev",
    "prod"
  ]
}

then in the script
cd "/mydir/$choose_environment/path"

[yosefy]

insted of
cd "/mydir/$1/path"

[yosefy]

or may be we could use the "param" without dashes as name

[bugy]

To be honest I'm confused. How are you using "param": "--env",?
And I guess in your example, you should reference the variable by $2 and not $1, right?
(I'm asking because I don't really understand the example).

But in general, as far as I understand, you would like that Script server will create environment variables based on parameters (and their) and pass them to a script, is it correct?
I think it would be possible, with replacing of unsupported characters (e.g. spaces)

Also Script server is based on the vision, that nobody will have a need to adjust their scripts for Script server :) And with this variables, your script would be almost unusable outside of Script server
Though for me this is not a problem. If you would like to adjust your script, it shouldn't be discouraged

[yosefy]

actually i am building my scripts for script-server in my case
so i think the best would be to turn

--test to "TEST"
--simple-bool to "SIMPLE_BOOL" and pass to script
(everything not a-z will turn to "_" )
then inside the script we don't have to remember what ${78} means :)

i think may be "param" is best candidate for the var name because it cant have spaces in it anyway
and if there is no param, no var

so that way scripts can continue running without script-server and still be logically connected to this way

may be you have better idea?

but again it is only for improvement. i am happy with script server anyway :)

[bugy]

I would use parameter name instead, because "param" should be used in a diferent manner (and it could be a single letter in a lot of cases).

But are you using "param" in your scripts at all? If you access parameters by index, then you don't need it.
I'm referring to this approach of using param: https://stackoverflow.com/a/14203146/2166673

Anyway, the idea itself makes sense

[yosefy]

amm i don't use it like this in this case (mostly using script server with ansible and terraform and packer for now)
about param you are right it is single latter sometimes
not sure need to add more fields put ok too
may be "name" is good candidate?

[bugy]

Name should be ok.

amm i don't use it like this in this case

But then you can skip specifying param all the time. It's not required :)

[yosefy]

yes i know but still you have to remember what is this $4 (or was it $3??) you see in the script
instead of $MEANINGFULL_NAME

example from real life :)

[bugy]

I agree with you, the whole ticket makes perfect sense.

By the way, why don't you set variables at the beginning of the script? It will make your life a little bit easier, I guess. Example:

#!/bin/bash

environment="$1"
user="$2"
command="$3"

cd "/mydir/$environment/path"

[yosefy]

well also an option :)

also to let you know
in ansible there is -e (external var) option, which you may add more then once
so in script-server this -e flags adds itself when the var is defined together with var(very useful!)

it solves many problems of not knowing the exact amount of vars that will be there in the end

so just wanted to thanks for that :)

[yosefy]

so another reason:

terraform apply -var "env=dev" -var "app=test" -var "size=6"

and i don't know how many there will be as they come from dynamically included config files for example

so, if "app" is not required and not set, then "size" will move from $6 to $4
and it may cause disaster :)

same with running ansible with multiple -e option or any other software of this type

so if we only use it with terraform command , then ok, we just add them all
BUT if in a script i wan't to run some other checks for example then i need to know the exact index
of the variable

so here turning name to ENV VAR as you suggested may fix the situation completely

thanks

[yosefy]

ok after trying all day :) need help
i want to do this
terraform apply $@
and that shoud do:
terraform apply -var env=dev -var app=test -var size=6 -var last_unknown=x

but i don't i can't find a way to do it
if i add param: "-var env="
then i get -var env= prod (with space)

@bugy , may be you have some idea?
thanks

[bugy]

Hi @yosefy, this is not possible, unfortunately. So as usual, my proposal would be some wrapping script. Which will read "normal" parameters and adapt them to the terraform syntax

[yosefy]

Ah right. Somehow I didnt think this way. I'll share if I manage to create one

…

On Mon, Feb 25, 2019, 9:39 PM Iaroslav Shepilov ***@***.***> wrote: Hi @yosefy <https://github.com/yosefy>, this is not possible, unfortunately. So as usual, my proposal would be some wrapping script. Which will read "normal" parameters and adapt them to the terraform syntax — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#181 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMVy7bpzl2BRSFWXF7A1jobE-gDAgh2Cks5vRDvpgaJpZM4a506_> .

[bugy]

Ok, if you would need help with it, I'd be glad to help

[muzzol]

I would like to resurface this issue as I'm using lot of scripts that uses environment variables to perform diferent operations. A very simple example:

SERVER_TYPE="prod" /opt/scripts/list-users.sh -a some -b params
I know I could use positional parameters, but I don't have always the same number of arguments so it can be very dificult to predict every combination.
With variables is very easy to do that.

There's a webmin plugin that handles that very well, you can specify any order an number of variables and you can construct the call to script in any way you want. Then you fill the variables with any value you want.

Here you can take a look:

what do you think about it?

[bugy]

Hi @muzzol, to be honest I never worked with webmin and not sure, what does this plugin do.

But in general is the idea is to pass parameters to scripts as environment variables, right? I.e. if you have parameters "Your name" and "Your password". In the script you would expect them to be available in $YOUR_NAME and $YOUR_PASSWORD env variables, right?

[yosefy]

Also somehow not to mix with regular placement depending vars I guess. May be make them like ENV_PASS. With ENV_ prefix

…

On Fri, May 17, 2019, 4:45 PM Iaroslav Shepilov ***@***.***> wrote: Hi @muzzol <https://github.com/muzzol>, to be honest I never worked with webmin and not sure, what does this plugin do. But in general is the idea is to pass parameters to scripts as environment variables, right? I.e. if you have parameters "Your name" and "Your password". In the script you would expect them to be available in $YOUR_NAME and $YOUR_PASSWORD env variables, right? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#181?email_source=notifications&email_token=ADCXF3P5HVBDVHJBBUU2RBDPV2ZJNA5CNFSM4GXHJ272YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVUZOKY#issuecomment-493459243>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADCXF3JYGZKLOXPHGYDVAYLPV2ZJNANCNFSM4GXHJ27Q> .

[muzzol]

Hi @muzzol, to be honest I never worked with webmin and not sure, what does this plugin do.

But in general is the idea is to pass parameters to scripts as environment variables, right?

yes, that's it.
for me the main concern is that lot of daily scripts don't have a fixed number of params. sometimes you can call a script with just one and the next time you call it with 8.
in addition to that, we also have scripts that react different depending on environment like in the first example I provided (SERVER_TYPE="prod")

maybe you could make a new parameter configuration, Environment Variable, that transforms that value in a variable just before script execution:

    {
      "name": "Multiple selection",
      "description": "Multiselect list",
      "type": "multiselect",
      "param": "SERVER_TYPE",
      "environment": true,
      "values": [
        "prod",
        "pre",
        "dev",
        "qua"
      ]
    },

this would be something like:

SERVER_TYPE="prod" /opt/test.sh

and if you want a variable from the whole environment you could use your ENV_ prefix trick.

[bugy]

Done. By default all parameters are mapped to PARAM_{uppercase name}, for example:
id -> PARAM_ID
Server Type -> PARAM_SERVER_TYPE

All whitespaces and special characters are replaced to a single underscore (_), e.g.:
hello !@#$%^& world -> PARAM_HELLO_WORLD

All non-ascii letters are tried to be transliterated, e.g.:
ῥυθμος -> PARAM_RYTHMOS

Buuut, if you want to be explicit, you can set a variable name yourself, using env_var field, e.g.:

{
      "name": "Required Text",
      "required": true,
      "param": "--required_text",
      "env_var": "Req_Text"
}

In this case the name will be exactly Req_Text and no transformations will be performed (even if the name is not supported).

The following parameters will not be set as env variables:

1. Empty values
2. List values ("type": "multiselect" and "multiple_arguments": true)
3. Non-ascii parameter names and if transliteration is not supported, e.g. japanese
4. no_value parameters, if the value is false
5. Parameters with a duplicated variable name (either copypasted env_var or name normalization is the same (e.g. Param ε and Param η are both resolved to PARAM_E)

PS this will be available in the dev build, and the new admin page already supports env_var

[bugy]

@Nottt FYI

[yosefy]

Yes! Hanuka miracle :)

…

On Wed, Dec 25, 2019, 6:46 PM Iaroslav Shepilov ***@***.***> wrote: Done. By default all parameters are mapped to PARAM_{uppercase name}, for example: id -> PARAM_ID Server Type -> PARAM_SERVER_TYPE All whitespaces and special characters are replaced to a single underscore (_), e.g.: hello !@#$%^& world -> PARAM_HELLO_WORLD All non-ascii letters are tried to be transliterated, e.g.: ῥυθμος -> PARAM_RYTHMOS Buuut, if you want to be explicit, you can set a variable name yourself, using env_var field, e.g.: { "name": "Required Text", "required": true, "param": "--required_text", "env_var": "Req_Text" } In this case the name will be exactly Req_Text and no transformations will be performed (even if the name is not supported). The following parameters will *not* be set as env variables: 1. Empty values 2. List values ("type": "multiselect" and "multiple_arguments": true) 3. Non-ascii parameter names and if transliteration is not supported, e.g. japanese 4. no_value parameters, if the value is false 5. Parameters with a duplicated variable name (either copypasted env_var or name normalization is the same (e.g. Param ε and Param η are both resolved to PARAM_E) PS this will be available in the dev build, and the new admin page already supports env_var — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#181?email_source=notifications&email_token=ADCXF3L6PID3G43MPR6LP3LQ2OE7LA5CNFSM4GXHJ272YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHUPKEA#issuecomment-568915216>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADCXF3IY6IHLPZRBLPBDV4TQ2OE7LANCNFSM4GXHJ27Q> .