Bug 131673

Created attachment 103418 [details]
patch to change trap usage

 I don't understand the point of these changes - please explain
 the problem they are designed to solve.
 
 The meaning of the 'trap' command usage does not seem to have 
 changed:

 From the bash-2.0 (1996) manpage:
   
 trap [-lp] [arg] [sigspec]
   The  command  arg  is  to  be  read  and executed when the shell
   receives signal(s) sigspec.  If arg is absent or -,  all  speci-
   fied signals are reset to their original values (the values they
   had upon entrance to the shell).  If arg is the null string this
   signal  is  ignored by the shell and by the commands it invokes.

 From the bash-3.0.5 (latest version) manpage:

 trap [-lp] [[arg] sigspec ...]
   The command arg is to  be  read  and  executed  when  the  shell
   receives  signal(s)  sigspec.   If arg is absent (and there is a
   single sigspec) or -, each specified  signal  is  reset  to  its
   original  disposition  (the  value  it  had upon entrance to the
   shell).  If arg is the null string the signal specified by  each
   sigspec  is ignored by the shell and by the commands it invokes.

So the intent of the commands such as
   trap 0 1 2 3 15
is to cause all the listed signals to be 
   "ignored by the shell and by the commands it invokes"
which is the same behaviour in bash-2.0 as in bash-3.0.5 .

So your changes will reset the signals to their original
disposition without ignoring them; this is not the intent
of the original commands, which is to ignore the signals.

Please explain why you want these changes made and what
problems they solve.

The point of these changes is that when bash 3.0 is run as /bin/sh 
instead of /bin/bash, "trap 0" syntax is not accepted:

$ /bin/bash
$ trap 0
$ exit
exit
$ /bin/sh
$ trap 0
trap: usage: trap [-lp] [arg|-] [signal_spec ...]
$ exit
exit
$ 

 I see the problem now - the bash maintainer confirms that
 bash-as-sh was changed intentionally to conform to POSIX
 syntax in this respect.
 
 Actually, on further investigation, the '#!@SHELL@' is 
 a configure-time option, and at the moment I can see no
 reason not to make @SHELL@ /bin/bash, which would also
 fix the problem with less patching required - I will test
 this, and if there are any problems, will revert to your
 patch with SHELL=/bin/sh.
   
 In any case, this will be fixed in the next mgetty release
 (mgetty-1.1.31-3).  

This is now fixed with bash-3.0-27 .