On 10/13/15 2:04 AM, Christoph Gysin wrote:
> On Sat, Oct 10, 2015 at 8:24 PM, Chet Ramey wrote:
>> I will consider adding an option to change the behavior of command
>> substitution inheriting the -e option, since there doesn't seem to be
>> any way to decouple this behavior from posix mode.
>
>
On Sat, Oct 10, 2015 at 8:24 PM, Chet Ramey wrote:
> I will consider adding an option to change the behavior of command
> substitution inheriting the -e option, since there doesn't seem to be
> any way to decouple this behavior from posix mode.
I added a patch:
https://savannah.gnu.org/patch/inde
Chet Ramey wrote:
On 10/2/15 9:22 AM, Greg Wooledge wrote:
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 fu
On 10/8/15 2:36 PM, Christoph Gysin wrote:
>> I think you're overlooking what I referred to above: that the exit status
>> of a command substitution doesn't have any effect on whether the parent's
>> command succeeds or fails except in one case: the right-hand-side of an
>> assignment statement tha
On Thu, Oct 08, 2015 at 09:36:59PM +0300, Christoph Gysin wrote:
> But this issue brings a new corner case:
>
> func() {
> cmd1
> cmd2
> }
>
> var=$(func)
>
> This won't work, because set -e is stripped inside the substitution,
> so the whole function runs without error checking.
> I know you don't want to hear this, but you really need to stop thinking
> of set -e as "error checking". It is an obsolescent historical anomaly
> that bash is required to support because POSIX specifies it. It isn't
> useful for any purpose, and people who insist on using it are simply
> caus
On 10/5/15 5:37 PM, Christoph Gysin wrote:
>> The parent shell (the one that enabled -e) should be the one to make the
>> decision about whether or not the shell exits. The exit status of the
>> command substitution doesn't make a difference except in one special case,
>> so inheriting errexit and
> I think you're overlooking what I referred to above: that the exit status
> of a command substitution doesn't have any effect on whether the parent's
> command succeeds or fails except in one case: the right-hand-side of an
> assignment statement that is the last assignment in a command consistin
> The parent shell (the one that enabled -e) should be the one to make the
> decision about whether or not the shell exits. The exit status of the
> command substitution doesn't make a difference except in one special case,
> so inheriting errexit and exiting (possibly prematurely) doesn't really
On 10/2/15 9:22 AM, Greg Wooledge wrote:
> 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 indepe
> 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 i
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
> Since it's a function, I would recommend return instead of exit. Also,
> you don't need the $? there. exit (or return) with no arguments will
> retain the exit status of the previous command.
Yes, $? is not needed.
exit or return is equivalent in this case though because of set -e.
> Putting
On Fri, Oct 02, 2015 at 02:09:21PM +0300, Christoph Gysin wrote:
> Since set -e does not work, it means I have to postfix every command
> with "|| exit $?":
>
> f() {
> some command || exit $?
> more commands --with-args || exit $?
> }
>
> output=$(f)
Since it's a function, I would recommend
> Yes, it's how bash has always behaved, at least back to bash-1.14 when
> I stopped looking. Around bash-2.05, it changed to preserve the -e
> option when in Posix mode.
Is there any reason not to preserve it?
> That exception from default bash behavior is documented in the Posix
> Mode section
> Whether e disappears from $- may be unintended, but what IS documented
> is that there are contexts in which set -e has no effect, and when in
> one of those contexts, you cannot re-enable set -e. One such context is
> on the left side of && or ||. Even more non-intuitively, if you have a
> fun
On 10/1/15 6:24 AM, Christoph Gysin wrote:
> It seems that set -e is stripped from the options ($-) when executing
> commands with command substitution:
>
> $ bash -euc 'echo $-; f(){ false; echo $->&2; }; x=$(f)'
> ehuBc
> huBc
>
> I would expect the shell to exit as soon as it executes 'false'.
On 10/01/2015 04:24 AM, Christoph Gysin wrote:
> It seems that set -e is stripped from the options ($-) when executing
> commands with command substitution:
>
> $ bash -euc 'echo $-; f(){ false; echo $->&2; }; x=$(f)'
> ehuBc
> huBc
>
> I would expect the shell to exit as soon as it executes 'fal
18 matches
Mail list logo
