Re: [lmi] Shell scripting bafflement

[Vadim Zeitlin]

On Thu, 27 Feb 2020 23:13:58 +0000 Greg Chicares <address@hidden> wrote:

GC> , but I'd like to ask a different question: what's the difference between
GC>   if $(curl some_URL >/dev/null 2>&1)
GC> and
GC>   if   curl some_URL >/dev/null 2>&1
GC> ?

 Well, to be honest, the main difference is that the latter is perfectly
normal and expected while the former is something weird I had never seen
before the start of the thread. Shell has a lot of dark corners (could it
be a distant relative of Shelob?) and I frankly don't think it's worth or
safe for one's sanity to try to deal with them. My advice would be to just
avoid them instead.

GC> In the examples quoted above, they appear to behave identically. I found
GC> that surprising. I understand that in
GC>   if   curl some_URL >/dev/null 2>&1
GC> the command's return code is 0 or not depending on the URL's reachability.
GC> However, here:
GC>   if $(curl some_URL >/dev/null 2>&1)
GC> I was expecting that
GC>  - the command would be run in a subshell
GC>  - the command's return code would vanish when that subshell returns

 From my point of view, this seems like a strange expectation because
normally the shell exits with the exit code of the command which ran in it:

        % /bin/sh -c 'exit 123' || echo $?
        123
        % /bin/sh -c /bin/false || echo $?
        1
        % /bin/sh -c /bin/true || echo $?
        % # nothing printed above, as expected

GC>  - the command-expansion's return code would be 0 if the subshell
GC>    executed the command
GC> but it seems that the command-expansion's return code is the
GC> command's return code.

 Yes, and this seems right and proper to me.

GC> The bash manual prescribes that:
GC> 
GC>   
https://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash.html#Simple-Command-Expansion
GC> | If one of the expansions contained a command substitution, the
GC> | exit status of the command is the exit status of the last
GC> | command substitution performed.
GC> 
GC> but AFAICT POSIX doesn't specify anything:
GC>   
https://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_03

 I can't indeed find anything about this in POSIX, but the fact that Dash
behaves like this makes me think that it might be still specified somewhere
because this shell authors would certainly have chosen a simpler way (and
not preserving the exit code is simpler than preserving it) if it were
legal from POSIX point of view as they seem to positively enjoy striving
for minimalism for its own sake.

GC> >  What can I say, nobody ever pretended shell wasn't confusing. IMHO this 
is
GC> > not the worst part, because typically once you realize the difference
GC> > between "if command" and "if test condition", things should be relatively
GC> > clear.
GC> 
GC> Yeah. Some languages were designed, and show a coherent set of design
GC> principles. OTOH, other languages (e.g., the shell grammar) have evolved,
GC> like a natural human language.

 From this point of view, it feels weird for an atheist like me to like
Perl family languages that are the best example of intelligent design I can
think of... But shell is too chaotic-evil even for me.

 Regards,
VZ

pgpH1VX37wYYm.pgp
Description: PGP signature