Re: [Help-bash] too paranoid?

[Bob Proulx]

Stephane Chazelas wrote:
> Bob Proulx:
> > Sorry but you have lost me.  Why won't the kill work on these other
> > shells?
> 
> I was about to offer a guess like the shell ignoring the signal
> during its handler, but it turns out it's just kill -s doesn't
> work properly in that version I tested on (pdksh 5.2.13), so you
> may ignore that part.

Oh!  Okay.  :-)

> Still
> 
> mksh -c 'trap : EXIT; trap "trap - INT;kill -s INT $$" INT; sleep 10'
> 
> exits with exit code 0, even with -o posix.

I played around some more with this and I see that mksh just appears
very buggy with respect to exit status.  I think there is a reason
that mksh is a second tier shell. :-(

I played around with mksh a little more and discovered that it
diverges significantly from ksh behavior.

> $ strace -e exit_group ./mksh -c 'kill $$'
> --- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=24839, si_uid=10031} 
> ---
> exit_group(143)                         = ?
> +++ exited with 143 +++
> 
> (I get the same with older versions).

Yep!  Looks buggy! :-(

> On your code (and mine), the shell would exit with 128+signum
> with the Bourne shell or ksh88 (and would with mksh if it
> weren't for the exit trap that resets the exit status to 0) so
> doing a exit 130 would have had the same effect (at least on
> Solaris 10 where I tested this on).
> 
> Note that the very reason $? is 128+n (and not 256+n or 65536+n
> that would remove the ambiguity) is so that it can be passed in
> an exit code.
> 
> In all of
> 
> sh -ec 'cmd; cmd2'
> sh -c 'cmd||exit; cmd2'
> sh -c 'if true; then cmd; fi' # except in shells that optimize out the fork
> mksh -c 'cmd'
> 
> except in ksh93, if cmd is killed, the shell will do an
> exit(128+signum). So when doing a system("cmd"), you already
> know that to check if cmd was killed by a signal, you need to
> check both "status & 63" for the signum if the process was
> killed, and code=status>>8, code > 128 && signum = code & 63, if
> the shell reports that the command (or itself like in the case
> of mksh) was killed.
> 
> IOW, exit code 130 is by convention already meant to convey a
> death-by-signal2 of a child process.

There is an old Gary Larson, The Farside, cartoon where the comment is
that, Yes, We know they are fools. But what type of fools are they?
Or something similar to that.  That is what this feels like.  We have
now determined that mksh is buggy.  We could spend much time
discussing how it is buggy.  But this is the help-bash list and bash
doesn't have any of those bugs.  I am going to stop analyzing this
here and simply say that bash does not have these bugs so okay to
proceed with bash.  (Or with /bin/sh which is typically dash because
dash is okay here too.  Although there are some sighandling
differences with dash as /bin/sh.)

> That's why I say it's marginally useful (when not inneffective
> like for Bourne or ksh88 or mksh as mentioned above).
> 
> Note that in all those cases above ksh93 will kill itself, with
> same signal, possibly generating an  extra core dump (possibly
> overwriting the previous one).
> 
> In anycase, what matters most here is that the exit status be
> non-zero as that's what the caller will likely care about.

Wouldn't it be great if everything just handled signals properly and
did the right thing?  That would be even better than the "not quite
bad enough to really break things" of mksh.

> For keyboard interrupt signals (SIGINT and SIGQUIT), killing
> yourself is desirable on systems that have shells that implement
> WCE like bash, as otherwise that would mean that if your script
> is called by another bash script, that other bash script
> wouldn't be interrupted when you press CTRL-C|\. But again, it's
> not always possible.

I was okay with what you said right up until you said that it is not
always possible.  At that point I think we can just agree to disagree.
Because I think it is certainly possible for software to operate
correctly.  It isn't even that difficult.  Mostly these corner case
problems comes from the author not knowing about the case.

Bob