azure-cli: "az vm run-command invoke" cannot pass parameters to a Linux machine via a script file
Describe the bug “az vm run-command invoke” cannot pass parameters to a Linux machine via a script file.
To Reproduce Make a file called script.sh containing:
#!/bin/bash
cd /home && echo "foo" >> test.txt && echo $1 >> test.txt
Execute the script above on a VM with Azure CLI with a command that looks like this:
az vm run-command invoke --resource-group MyRG --name MyVM --command-id RunShellScript --scripts '@script.sh' --parameters bar
If I log into the VM in Azure and cat /home/test.txt it gives me:
foo
Where is “bar”?
Expected behavior
Now I directly run the following Azure CLI command:
az vm run-command invoke --resource-group MyRG --name MyVM --command-id RunShellScript --scripts 'cd /home && echo "foo" >> test.txt && echo $1 >> test.txt' --parameters bar
If I now log into the VM in Azure and cat /home/test.txt it gives me:
foo
bar
This is how I expect it to be.
Furthermore, this bug does not happen when executing a PowerShell script on Windows…
Additional context I tries this (and ton of other stuff). Nothing worked to get the parameters into the shell script.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 20 (7 by maintainers)
@Drewm3 this is not resolved - the string interpolation that’s occuring isn’t correct - or not documented. Specifically, omitting the
#!/bin/...line is a super weird thing and non intuitive for linux users.This issue was fixed end of April 2020.
Parameter enumeration start from 0 instead of 1. The difference is that parameters definition is embedded in the script instead of passed outside in a command line (where $0 is equals to bash). If you see the example we start from $0: echo $0 $1
About the other issue where script starts with #!/bin/bash I discovered a bug in the parameter inserting logic where we insert the parameter definition after the first line if starts with #! The problem is the whole script is in one string and all parameter definition ends up inserted after the script. We will fix that and new release is expected to deploy by the end of April 2020.
Sorry for the long delay. Anyway, I tried.
Running the command you state works. Probably because it gets executed as two separate scripts. Running the script with Unix line endings doesn’t work.