On Fri, Dec 23, 2016 at 02:35:06PM +1100, Russell Coker wrote:
Putting the -e in the first line of the shell script is considered bad practice anyway.
that's debatable. some think it's bad practice. some think it's using bash as it's documented to work. 'bash -e' was just a simple example (and it's easy enough to just have 'set -e' in the script itself), not the beginning or end of the problem. As mentioned, the problem is even worse if used with other languages. e.g the following perl script works and produces useful (and expected) output: #!/usr/bin/perl -p s/foo/bar/; This doesn't: #!/usr/bin/perl s/foo/bar/; for those not familiar with perl, `-p` tells perl to wrap the entire script (aside from a few exclusions like BEGIN and END blocks) in a while/read/print loop on STDIN+filename args, so the former script actually runs as if the code is more like this (slightly simplified): #!/usr/bin/perl while (<>) { s/foo/bar/; print "$_"; } see `man perlrun` for more details. and note that it gets even more complicated when other options are also used - e.g. see the example given for '#!/usr/bin/perl -pi.orig'
If correct operation of the script requires aborting on error then you don't want someone debugging it with "bash -x scriptname" to accidentally stop that.
as with most things, there are pros and cons to that. sometimes you want -x to override -e, sometimes you don't. and you can always "override the override" by running 'bash -x -e scriptname' the point is that #!/usr/bin/env breaks the documented behaviour of interpreters, preventing scripts from being run with any options that they may require. craig -- craig sanders <cas@taz.net.au>