Bug 131673

Summary: faxrunq incompatible with current bash
Product: [Fedora] Fedora Reporter: Jonathan Kamens <jik>
Component: mgettyAssignee: Jason Vas Dias <jvdias>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhide   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: bash-3.0+ Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-02-21 16:23:16 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 123268, 136451    
Attachments:
Description Flags
patch to change trap usage none

Description Jonathan Kamens 2004-09-03 02:05:40 UTC
The "trap 0 ..." syntax in /usr/bin/faxrunq in mgetty-sendfax is
incompatible with bash 3.  See attached patch.

Comment 1 Jonathan Kamens 2004-09-03 02:06:29 UTC
Created attachment 103418 [details]
patch to change trap usage

Comment 2 Jason Vas Dias 2004-09-03 14:41:25 UTC
 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.



Comment 3 Jonathan Kamens 2004-09-03 15:48:09 UTC
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
$ 


Comment 4 Jason Vas Dias 2004-09-03 17:07:20 UTC
 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).  


Comment 5 Jason Vas Dias 2005-02-21 16:23:16 UTC
This is now fixed with bash-3.0-27 .