Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #11576
| From | Greg Wooledge <wooledg@eeg.ccf.org> |
|---|---|
| Newsgroups | gnu.bash.bug |
| Subject | Re: command substitution is stripping set -e from options |
| Date | 2015-10-02 09:22 -0400 |
| Message-ID | <mailman.277.1443794710.16064.bug-bash@gnu.org> (permalink) |
| References | <CADex794C1jOf0wrB298_O4ohAqZghYUdd9DJcuaOvV1dCP5AOQ@mail.gmail.com> <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> |
On Fri, Oct 02, 2015 at 03:53:42PM +0300, Christoph Gysin wrote: > I'm still curious as to why set -e is stripped in the first place? 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. 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
Back to gnu.bash.bug | Previous | Next | Find similar
Re: command substitution is stripping set -e from options Greg Wooledge <wooledg@eeg.ccf.org> - 2015-10-02 09:22 -0400
csiph-web