Bug#1016049: coreutils: env --{default,ignore,block}-signal with empty argument is valid and does nothing?

Pádraig Brady Tue, 26 Jul 2022 04:57:27 -0700

On 26/07/2022 05:46, наб wrote:

Package: coreutils
Version: 8.32-4+b1
Severity: minor


Dear Maintainer,

Quoth upstream NEWS:
-- >8 --
* Noteworthy changes in release 8.31 (2019-03-10) [stable]

** New features

   env now supports '--default-signal[=SIG]', '--ignore-signal[=SIG]', and
   '--block-signal[=SIG], to setup signal handling before executing a program.

   env now supports '--list-signal-handling' to indicate non-default
   signal handling before executing a program.
-- >8 --

Quoth env(1):
-- >8 --
        --block-signal[=SIG]
               block delivery of SIG signal(s) to COMMAND

        --default-signal[=SIG]
               reset handling of SIG signal(s) to the default

        --ignore-signal[=SIG]
               set handling of SIG signals(s) to do nothing

        SIG may be a signal name like 'PIPE', or a signal number like '13'.  
Without SIG, all known signals are included.  Multiple signals can be 
comma-separated.
-- >8 --

However:
-- >8 --
$ env -v --block-signal=1 ls /dev/null
signal HUP (1) mask set to BLOCK
executing: ls
    arg[0]= ‘ls’
    arg[1]= ‘/dev/null’
/dev/null
$ env -v --block-signal ls /dev/null 2>&1 | paste - - - -
signal HUP (1) mask set to BLOCK        signal INT (2) mask set to BLOCK        
signal QUIT (3) mask set to BLOCK       signal ILL (4) mask set to BLOCK
signal TRAP (5) mask set to BLOCK       signal ABRT (6) mask set to BLOCK       
signal BUS (7) mask set to BLOCK        signal FPE (8) mask set to BLOCK
signal KILL (9) mask set to BLOCK       signal USR1 (10) mask set to BLOCK      
signal SEGV (11) mask set to BLOCK      signal USR2 (12) mask set to BLOCK
signal PIPE (13) mask set to BLOCK      signal ALRM (14) mask set to BLOCK      
signal TERM (15) mask set to BLOCK      signal STKFLT (16) mask set to BLOCK
signal CHLD (17) mask set to BLOCK      signal CONT (18) mask set to BLOCK      
signal STOP (19) mask set to BLOCK      signal TSTP (20) mask set to BLOCK
signal TTIN (21) mask set to BLOCK      signal TTOU (22) mask set to BLOCK      
signal URG (23) mask set to BLOCK       signal XCPU (24) mask set to BLOCK
signal XFSZ (25) mask set to BLOCK      signal VTALRM (26) mask set to BLOCK    
signal PROF (27) mask set to BLOCK      signal WINCH (28) mask set to BLOCK
signal POLL (29) mask set to BLOCK      signal PWR (30) mask set to BLOCK       
signal SYS (31) mask set to BLOCK       signal RTMIN (34) mask set to BLOCK
signal RTMIN+1 (35) mask set to BLOCK   signal RTMIN+2 (36) mask set to BLOCK   
signal RTMIN+3 (37) mask set to BLOCK   signal RTMIN+4 (38) mask set to BLOCK
signal RTMIN+5 (39) mask set to BLOCK   signal RTMIN+6 (40) mask set to BLOCK   
signal RTMIN+7 (41) mask set to BLOCK   signal RTMIN+8 (42) mask set to BLOCK
signal RTMIN+9 (43) mask set to BLOCK   signal RTMIN+10 (44) mask set to BLOCK  
signal RTMIN+11 (45) mask set to BLOCK  signal RTMIN+12 (46) mask set to BLOCK
signal RTMIN+13 (47) mask set to BLOCK  signal RTMIN+14 (48) mask set to BLOCK  
signal RTMIN+15 (49) mask set to BLOCK  signal RTMAX-14 (50) mask set to BLOCK
signal RTMAX-13 (51) mask set to BLOCK  signal RTMAX-12 (52) mask set to BLOCK  
signal RTMAX-11 (53) mask set to BLOCK  signal RTMAX-10 (54) mask set to BLOCK
signal RTMAX-9 (55) mask set to BLOCK   signal RTMAX-8 (56) mask set to BLOCK   
signal RTMAX-7 (57) mask set to BLOCK   signal RTMAX-6 (58) mask set to BLOCK
signal RTMAX-5 (59) mask set to BLOCK   signal RTMAX-4 (60) mask set to BLOCK   
signal RTMAX-3 (61) mask set to BLOCK   signal RTMAX-2 (62) mask set to BLOCK
signal RTMAX-1 (63) mask set to BLOCK   signal RTMAX (64) mask set to BLOCK     
executing: ls      arg[0]= ‘ls’
    arg[1]= ‘/dev/null’  /dev/null
$ env -v --block-signal= ls /dev/null
executing: ls
    arg[0]= ‘ls’
    arg[1]= ‘/dev/null’
/dev/null
-- >8 --

Precedent dictates that an empty argument should be refused (right?),
practicality suggests that it's likely a mistake
(since, again, it does nothing).
and the manual says it's forbidden
(clumsily using SIG and prose to describe signal[,signal]...).

Best,
наб

-- System Information:
Debian Release: 11.4
   APT prefers stable-updates
   APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-16-amd64 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages coreutils depends on:
ii  libacl1      2.2.53-10
ii  libattr1     1:2.4.48-6
ii  libc6        2.31-13+deb11u3
ii  libgmp10     2:6.2.1+dfsg-1+deb11u1
ii  libselinux1  3.1-3

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information



Not a bug I think.

"Empty" and "No" arguments are separate cases.
I.e. `env --block-signal=` is equivalent to `env --block-signal ""`.
This distinction is useful if passing a dynamic arg like:
  env --block "$SIGS_TO_BLOCK"

thanks,
Pádraig

Bug#1016049: coreutils: env --{default,ignore,block}-signal with empty argument is valid and does nothing?

Reply via email to