Ole Tange writes:
> The reason is for people that make scripts for others to run. E.g:
>
> #!/usr/bin/tcsh
>
> parallel 'setenv FOO bar; echo $FOO {}' ::: foo
>
> This example uses 'setenv' which does not exist in bash.
Writing scripts for others to run takes a lot more care, so that user is
quite likely to shoot himself in the foot some lines further.
> If your login $SHELL is bash, then running that script will fail,
> because GNU Parallel 20140722 will use $SHELL. The script coder's
> login $SHELL is probably tcsh, so the script will work for him. This
> goes against principle of least astonishment: We expect the same
> script to behave the same way - no matter which login $SHELL we call
> it from.
I could quite reasonably expect other things to happen.
> This also shows you how to force GNU Parallel to use /bin/dash: Either
> make a script (starting with #!/bin/dash) or use:
>
> dash -c 'parallel ....'
I know, but that doesn't invalidate the point that you're going to force
people to switch from a well known idiom and change code that relies
wittingly or unwittingly on SHELL and that can quite possibly fail to
recognize the correct shell the user intended to run. What if the login
shell is /bin/false, for instance? When I run things over ssh I often
never run a login shell at all.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada
