Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #11577

Re: command substitution is stripping set -e from options

From Christoph Gysin <christoph.gysin@gmail.com>
Newsgroups gnu.bash.bug
Subject Re: command substitution is stripping set -e from options
Date 2015-10-03 11:35 +0300
Message-ID <mailman.343.1443861355.16064.bug-bash@gnu.org> (permalink)
References (1 earlier) <560D83DA.9020405@redhat.com> <CADex795r=oqZ7iv4TxrjUn9coDUnu=PgPngkfRWA1f7EZyohfA@mail.gmail.com> <20151002122925.GK25574@eeg.ccf.org> <CADex797-gWHRzpy=gsdORZtU=Os5Qe6f=LwJ7xJ-N-6oHZdd3w@mail.gmail.com> <20151002132221.GL25574@eeg.ccf.org>

Show all headers | View raw


> Chet can give the definitive answer, but my take is that it's a huge
> surprise to someone writing a function independent of the script, or
> using a function that was written independently of the script.  If the
> function does not expect set -e to be in effect (which is not the default,
> and is not done in any sane environment, so why would anyone EXPECT it?)
> then it may have been written to work in a normal environment, and will
> fail in a set -e environment.

Yes, obviously you can't just source other bash files and assume they
work with set -e (or set -u for that matter). But if I do I still have
the option of consciously disabling said options with set +e.

> I have many examples of commands that surprisingly explode and set your
> house on fire when run in a set -e environment, but which work perfectly
> well in a regular environment.  See http://mywiki.wooledge.org/BashFAQ/105

Thanks for that excellent resource!

Maybe I spent too much time with bash scripts, but I'm already aware
of all those corner cases. Yes they are not pretty, but for each of
them there is a simple workaround. Tools like shellcheck will even
warn you about some of them.

The behaviour I describe seems to fall in a different category though.
Switching to posix mode has all kinds of other side effects, so I
don't think that's a valid workaround.

And it seems that the code to inherit set -e is already there, just
not enabled by default. This seems to cause behaviour that is
counter-intuitive IMO.

Chris

Back to gnu.bash.bug | Previous | Next | Find similar


Thread

Re: command substitution is stripping set -e from options Christoph Gysin <christoph.gysin@gmail.com> - 2015-10-03 11:35 +0300

csiph-web