bug-gawk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-gawk] system() should return != 0 when the process is killed


From: Stephane CHAZELAS
Subject: Re: [bug-gawk] system() should return != 0 when the process is killed
Date: Fri, 11 Mar 2016 09:40:23 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

2016-03-11 10:20:39 +0200, Aharon Robbins:
> > To: address@hidden
> > From: Stephane Chazelas <address@hidden>
> > Date: Thu, 10 Mar 2016 21:45:42 +0000
> > Subject: Re: [bug-gawk] system() should return != 0 when the process is
> >     killed
> >
> > So why not doing the same thing as mawk here (see my other
> > posts)?
> 
> Because it's not right. Ignoring the fact that mawk dies upon
> receipt of a signal, here is what mawk returns. This is from the
> original mawk-1.3.3, function wait_for() in files.c
[...]

That would be a feature. The reason shells set $? as 128+signum
is not because their authors are stupid and can't see it causes
ambiguity but because that's how you can carry the information
about a dead child in an exit status (where, when you use the
wait() interface as opposed to waitid() (on some systems) only
the first 8 bits are available to the parent).

That's needed when a shell wrapper wants to report the exit
status of a child.

By convention, an error code of 138 indicates the death by
signal 10 of a process. In most shells, a death by signal 10 and
a death by exit(138) are not distinguishible and you generally
don't want to distinguish them because they  are meant to mean
the same thing.

When you do:

sh -c 'cmd; exit'

Or

sh -ec 'cmd;cmd2'

Or

sh -c 'cmd || exit; echo OK'

(And even sh -c cmd (so system("cmd")) for some signals in some
shells like SIGINT on mksh)

In most shells, if cmd is killed, the shell will do a
exit(128+signum).

The alternative to that is ksh93 where $? is 256+signum (core
bit removed), and upon "exit" ksh93 kills itself (possibly
generating its own core file in a different location or
overwriting the first one, and other possible side effects) so
as to report the same waitpid() exit status as the child. IMO,
the ksh93 behaviour is not desirable.

A potentially better behaviour (and I think I've mentioned that
already) is the "yash" shell behaviour where $? is 256+128+$?, so
that within your "yash" script, you can differentiate a death by
sig 10 and a death by exit(138) (again, not that you would
generally want to), and still with an exit(256+128+10), parents
see a 138 as with traditional shells.

-- 
Stephane



reply via email to

[Prev in Thread] Current Thread [Next in Thread]