Closed l1n3n01z closed 3 months ago
Hi, is it merely because of convenience?
The reason I'm asking is because scripting out having arguments last after some special syntax such as '--' via a wrapper-script is very doable and doesn't introduce another syntax for something that is already solved via widely used methods.
Closing due to inactivity.
For reference, here's a bash-script that inverts the way variables are passed:
#!/bin/bash
delim_found=false
for arg in "$@"; do
if $delim_found; then
env_vars+=("$arg")
elif [ "$arg" == "--" ]; then
delim_found=true
else
command_args+=("$arg")
fi
done
# Execute the command with environment variables first
env "${env_vars[@]}" ain "${command_args[@]}"
Usage with script saved as ain.sh. A single --
delimiter between command line arguments and variables:
ain.sh template1.ain template2.ain -- VAR1=1 VAR2=2
Hi @l1n3n01z ! I thought about this some more and decided to add --vars VAR=value
as documented here thanks to your issue!
Not only does it make arrow up easier, but on windows cmd.exe setting environment-variables is involved, and --vars will help there.
It's on master right now but hasn't been released yet.
Passing variables as environment variables is fine for configuration variables, but having used ain a bit, I feel that passing variables as arguments would be much more natural when the variable in question varies often. This applies both when scripting and on the command line.
Using a double hyphen to denote that the following arguments are variables might be a good way to do this. It would allow easy editing of parameters when calling the same endpoint a few times.
$ ain -e config.env base.ain specific_query.ain -- --id=2
push up arrow and change the id$ ain -e config.env base.ain specific_query.ain -- --id=3
When scripting
NB: I'm using camelCase for my variables that I know change often
Before
After