aborting a bash script with control-c
in [Shell]
|
From: Ben Bacarisse on 9 Jun 2010 13:25 Chad <cdalten(a)gmail.com> writes: > On Jun 9, 6:27 am, Ben Bacarisse <ben.use...(a)bsb.me.uk> wrote: <snip> >> It is clear that "trap - INT" is the form to choose. > > I think I just missed something here. Why would you use "trap - INT" > and not something like "trap - SIGINT"? Portability. SUS[1] permits but does not require that signal names with the SIG prefix work. INT must work on all SUS shells, and SIG is permitted but you can't be sure it will work. [1] Single Unix Specification. I think this is more correct that the old term POSIX though I have to keep reminding myself not to type POSIX. -- Ben.
From: Geoff Clare on 10 Jun 2010 08:39 Ben Bacarisse wrote: > SUS[1] > [1] Single Unix Specification. I think this is more correct that the > old term POSIX though I have to keep reminding myself not to type > POSIX. Saying just "POSIX" is (in the comp.unix.* newsgroups, anyway) normally understood as meaning POSIX.1. Since 2001, SUS and POSIX.1 are one and the same document, and both names are valid, although the document refers to itself internally as POSIX.1. (For the nit-pickers: I said "SUS" above for brevity, but it would be more correct to say "the base volumes of SUS", since SUS has an extra XCurses volume.) -- Geoff Clare <netnews(a)gclare.org.uk>
From: Geoff Clare on 10 Jun 2010 11:50
Ben Bacarisse wrote: > Geoff Clare <geoff(a)clare.See-My-Signature.invalid> writes: > >> Ben Bacarisse wrote: >> >>> To return to whatever the default is use: >>> >>> trap SIGINT >>> >>> or >>> >>> trap - SIGINT >> The second of those will work (if, as Martin Vaeth pointed out, the >> shell accepts the SIG prefix, which POSIX doesn't require). However, >> the first will give an error message in bash and ksh (even though >> they support the SIG prefix), as the operand "SIGINT" is taken as an >> action to perform, and no conditions have been specified for that >> action. The first form only works with numeric signals, e.g. "trap >> 2". > > That seems to be true for ksh but not for bash, at least not for recent > bash versions. At first I assumed that you must have a later version of bash than me, but on further investigation it seems to be one of the things that bash does differently if invoked as "sh": $ readlink /bin/sh bash $ bash -c 'trap INT' $ sh -c 'trap INT' trap: usage: trap [-lp] [arg signal_spec ...] -- Geoff Clare <netnews(a)gclare.org.uk> |