execline
Software
www.skarnet.org
The execlineb and execline launchers store positional parameters, i.e. arguments given to your script, into the environment. The # variable contains the number of arguments; the 0 variable contains the name of your execline script; the 1 variable contains the first argument; and so on.
Up to execline-1.04, this could create problems with nested scripts: the inner script would overwrite the outer script's parameters, and there was no way to get them back. In particular, writing execline commands in the execline language via the runblock command was impossible.
To solve that issue, execline-1.05 implements a kind of environment stack. When the execline(b) launcher reads the arguments, it does not overwrite the positional parameters, but pushes them on a stack:
The script then runs; commands such as elgetpositionals use the current frame of positional parameters, without paying attention to the deeper levels.
When you are done with the arguments, it is advisable to drop the current frame, and pop the environment stack to get it back to its previous state:
Suppose you want to run the long-lived program prog after printing the list of its arguments.
#!/command/execlineb elgetpositionals foreground { echo $0 $@ } prog $@will work, but will pollute prog's environment with a set of positional parameters that have no meaning to it. A better script is:
#!/command/execlineb elgetpositionals foreground { echo $0 $@ } emptyenv -P prog $@which will run prog with the same environment as the script's caller.