Robert Elz <k...@munnari.oz.au> wrote, on 17 Apr 2019: > > | My chain of reasoning is ... > | > | The standard says "Signals that were ignored on entry to a > | non-interactive shell cannot be trapped or reset, although no error > | need be reported when attempting to do so". > > It does. > > | This means that if "trap some_command INT" or "trap - INT" is > | executed in a shell that had SIGINT ignored on entry, the allowed > | behaviours are for trap to fail and report an error, > > Perhaps, though as discussed earlier, no-one is going to do that, ever. > > | or for it to exit with status 0 without > | changing the action for the INT condition. > > Perhaps, but you forgot one > > or for it to exit with status 0 after changing the action > for the INT condition, while still allowing the signal to > remain ignored.
No, that is not allowed. The standard says "cannot be trapped". It doesn't refer to the underlying signal disposition, it uses the word "trapped" which is the shell concept. Executing trap with no arguments shows what the current traps are. If a signal cannot be trapped, then trap with no arguments must not show that it is trapped. > | Since an attempt to trap such a signal must fail or be silently > | ignored, > > You are assuming too much, there is no such requirement. Please do > remember that the words you quoted do not say > > If a signal was ignored on entry to a non-interactive shell > the shell shall ignore any attempt to change the trap, though > it need not report an error while so doing. > > Written that way it would be a requirement of the standard. As it > is written it is simply advising people that they cannot expect to > catch (or be terminated by) any signal that was ignored on entry to > a non-interactive shell. You are willfully misinterpreting the words in the standard. It most definitely is a requirement on the implementation. In an earlier email you made much the same claim, saying something about "cannot" not being in XBD 1.5. I didn't reply to that because it was so ridiculous that I didn't want to embarrass you. The word "cannot" is simply a contraction of "can not". The word "can" is the first entry in XBD 1.5. I assume you aren't going to claim that anywhere the standard says "shall not" this is not a requirement because only the positive form "shall" is in XBD 1.5. > > | shells which produce output (or lack of it) that indicates the default > | action for INT clearly do not conform. > > So, aside from bash, which shells do conform? Does the Solaris > shell conform to your view of how this should work? That is, the > one used for POSIX certification. Irrelevant. We're discussing what the standard requires, not what implementations do. > And again, your are confusing the signal state with the shell trap > state, the two are (quite often) not the same. No, you are misinterpreting the standard as talking about the signal state when it is clearly referring to the shell trap state. > | Slightly less clear, but given the above it is the only behaviour > | that makes sense, > > This I believe is the underlying problem. You have a veiw of what you > believe makes sense, and you are forcing yourself to read the standard > to conform with that view, rather than reading what it actually says. > > I will ask once again, since you have ignore every previous attempt > to get an answer to this question. > > If the standards writers in 1992 (or any time since) really intended the > standard to say what you believe it says, and given the (probably zero) > shells that acted like this in 1992, as even bash 2.x (more recent than > 1992) does ... > > bash2 $ (trap '' INT EMT; $SHELL -c trap) > bash2 $ (trap '' INT EMT; $SHELL -c 'trap "echo foo" INT; trap') > bash2 $ (trap '' INT EMT; $SHELL -c 'trap "" INT; trap') > trap -- '' SIGINT > bash2 $ (trap '' INT EMT; $SHELL -c 'trap "" INT; trap - INT; trap') > bash2 $ > > then why is there no rationale explaining why things were to be different > than what (apparently) *every* shell did (there are rationales for other > changes of a similar nature - though usually at least some shell(s) already > did what the standard was requiring) I can't answer that because I wasn't involved when POSIX.2-1992 was developed. Possibilities include that the problem never came up, or that it was discussed and a decision made, but it was one of many such decisions and busy people did not think to suggest adding rationale about it. > and why is there not a single example > in the application usage on this point? Same answer. -- Geoff Clare <g.cl...@opengroup.org> The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
