Robert Elz <k...@munnari.oz.au> wrote, on 15 Apr 2019: > > Taking this (slightly) out of order... > > | In an interactive shell, the "trap - $sig" should work, and so the > | signal will not be listed. > > Huh? What "trap - $sig" ?
The one three lines above that in my email. (Which is now below, because of your reordering.) > In the context of an interactive shell, where the very > first command exectued is > > trap > > what should be output, given that siglals X Y and Z were ignored > when this interactive shell started ? (And the shell has not forced > them back into their default state). The output should be a command that sets signals X Y and Z to be ignored. > If that is not the same as: > > | Where the resolution says: > | > | The trap command with no operands shall write to standard output a > | list of commands associated with each of a set of conditions; if > | the -p option is not specified, this set shall contain only the > | conditions that are not in the default state (including signals > | that were ignored on entry to a non-interactive shell) > | > | the part in parentheses is a clarification that the signals that > | were ignored on entry to a non-interactive shell must be listed as > | ignored, > > for a non-interactive shell, then why is it different? It's the same for the specific case you stated. It is different in other cases, e.g. if the shell reset X Y and Z to default, or if there has been a "trap - X Y Z" executed beforehand. > | even if the script has executed "trap - $sig" to (try to) This is the "trap - $sig" that you asked about above. > | reset that signal (and the shell didn't report an error). > > That would be unusual behaviour, I have not seen scripts bother to start > attempting to reset signals to the default, except when the aim > is to reset an earlier trap command. > > There is no point, if we have not changed the trap, it is already > at its default state - unless it was ignored on entry. In the latter > case in a non-interactive shell there is no point (currently anyway) > trying to reset it to default, as that will not work. That is, the > only place where it even makes sense to start wuth "trap - $sig" is in an > interactive shell. I don't believe doing that is commonplace... I agree there's no point trying to do it in a non-interactive shell. But I don't see that as justification for stopping the standard from specifying the behaviour if a script did try to do it. > But if that has been done, then the signal will be at its default state, > and it would make sense to not report it as ignored. But if it > has not been done, and in the interactive shell the signal remains > ignored, should not that be reported just as it is to be in a > non-interactive shell? Of course. The difference is that for a non-interactive shell, signals that were ignored on entry to the shell are *always* reported by trap as ignored, no matter what else has happened. For an interactive shell, signals that were ignored on entry to the shell can be reset by the shell or by a later trap command, and so trap just works "normally"; there is nothing noteworthy about the trap output in this case. > In any case, the wording in parentheses needs fixing, I would suggest > that it should become (something like) > > (any signals that were ignored upon entry to the shell, > and which remain ignored, shall be included in the output > and reported as ignored) I disagree that it needs fixing. The current resolution is calling out a special case for non-interactive shells. Your suggestion applies to both interactive and non-interactive shells, and so doesn't highlight that the there is something special about the non-interactive case. > | We felt that for shells where trap lists something that does not reflect > | what the shell will actually do, that's a bug in the shell. > > That's OK by me, but as it is a change from what every shell except > bash currently does, an explanation for this needs to go into the > rationale (along with that for the addition of -p). The behaviour of these shells also doesn't conform to the requirements of the current standard. The bug 1212 resolution doesn't alter the required behaviour for ignored signals (it just adds an explanation of one aspect of it). So I don't see the need to mention it in rationale. It is simply a bug that shell authors should fix. > It should also be clear that by doing this we're taking a position on > the purpose of the (bare) trap ... that is, that it is to report what > will happen when a signal is received. > > An alternative view is that it is to report the traps that have been > set (or attempted to be set) in this shell (so they can be repeated > later). The standard clearly states that signals ignored on entry to a non-interactive shell *cannot* be trapped or reset. If, after an attempt has been made to set a trap, the trap output shows something other than that the signal is set to ignored, then shell has not obeyed this requirement. > It is also worth nothing, that some shells (perhaps most shells) do permit > (some) signals to be trapped, even when they were ignored on entry. Those > are typically the signals that the shell does not allow to remain ignored > (like SIGCHLD) because doing so would adversely affect the operation of the > shell. That is, rather than "on entry to the shell" the actual criterion > in practice is "after shell initialisation". There is certainly an issue with SIGCHLD, but it's a separate issue that should be the subject of a separate bug. -- Geoff Clare <g.cl...@opengroup.org> The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
