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

Groups > gnu.bash.bug > #16354

Re: local failure

Show key headers only | View raw

Laurent Picquet <lpicquet@gmail.com> writes:
> Should the 'local' command be the one able to detect that the assignment to
> the variable had an non-zero exit code and return the non-zero exit code?

John Passaro <john.a.passaro@gmail.com> writes:
> I think the underlying question here is not exactly "how do I gather this
> from the docs" as much as it is "how was I supposed to know about this and
> act on it before I had to debug it?"

>From where I stand, the situation appears differently.  I knew that the
the exit code from the command inside $( ... ) is ignored.  So when
someone complained that
    FOO=$( false) 
exits 1 but
    echo $( false )
exits 0, my reflex was that the first one was a bug.

It was only when I went to the man page and read up did I discover to my
surprise that the exit status of $( ... ) in standalone assignments is
the exit status of the assignment.

So my first answer is "You're supposed to know that the exit status of
$( ... ) is discarded as it is a fundamental property of command
substitution."  Other than for the fact that it's only sometimes true...

I would argue that "local" should not have any special behavior in
regard to command substitution, as that would be Yet Another Special
Case.

Though it seems to me that one can get finer control over command
substitution by doing:

    FOO="$( command1 )"
    # Test $? here to find out what command1 did.
    command2 $FOO
    # Test $? here to find out what command2 did.

No doubt the special case for how command substitution exit statuses in
standalone assignments are handled was done specifically to make this
possible.

Dale

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

Thread

Re: local failure worley@alum.mit.edu (Dale R. Worley) - 2020-06-02 21:42 -0400

csiph-web