On Tue, Jul 26, 2022 at 12:56:06PM +0100, Pádraig Brady wrote: > On 26/07/2022 05:46, наб wrote: > > Package: coreutils > > Version: 8.32-4+b1 > > Severity: minor > > > > 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 -- > > > > 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]...). > 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" Sure, I don't disagree that's useful, but the manual specifies that at least one signal is required.
Consider instead the following:
-- >8 --
--block-signal[=SIGS]
--default-signal[=SIGS]
--ignore-signal[=SIGS]
block delivery of SIGS signals to COMMAND
SIGS is a comma-separated list of signal names like 'PIPE' or
signal numbers like '13'.
-- >8 --
Which describes this accurately,
and could be resugared as --block-signal[=[signal[,signal]...]].
> thanks,
> Pádraig
Best,
наб
signature.asc
Description: PGP signature
