[1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
The following issue has a resolution that has been APPLIED. == https://austingroupbugs.net/view.php?id=1212 == Reported By:kre Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1212 Category: Shell and Utilities Type: Enhancement Request Severity: Objection Priority: normal Status: Applied Name: Robert Elz Organization: User Reference: Section:XCU 2.14 -- trap special builtin Page Number:2420 - 2423 Line Number:77484-5 (and more) Interp Status: --- Final Accepted Text:https://austingroupbugs.net/view.php?id=1212#c4358 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2018-09-28 02:56 UTC Last Modified: 2020-04-27 11:18 UTC == Summary:Enhance trap command == Relationships ID Summary -- related to 0001211 trap (with no args) specifi... == Issue History Date ModifiedUsername FieldChange == 2018-09-28 02:56 kreNew Issue 2018-09-28 02:56 kreName => Robert Elz 2018-09-28 02:56 kreSection => XCU 2.14 -- trap special builtin 2018-09-28 02:56 krePage Number => 2420 - 2423 2018-09-28 02:56 kreLine Number => 77484-5 (and more) 2019-04-04 17:35 shware_systems Note Added: 0004356 2019-04-06 07:54 kreNote Added: 0004357 2019-04-09 11:07 geoffclare Note Added: 0004358 2019-04-09 11:09 geoffclare Note Edited: 0004358 2019-04-09 11:11 geoffclare Note Edited: 0004358 2019-04-09 11:13 geoffclare Note Edited: 0004358 2019-04-09 11:19 geoffclare Relationship added related to 0001211 2019-04-09 13:32 joerg Note Added: 0004359 2019-04-09 13:35 joerg Note Edited: 0004359 2019-04-09 13:52 geoffclare Note Edited: 0004358 2019-04-09 14:27 nick Note Added: 0004360 2019-04-10 08:33 geoffclare Note Edited: 0004358 2019-04-11 15:33 geoffclare Note Edited: 0004358 2019-04-11 15:48 geoffclare Interp Status => --- 2019-04-11 15:48 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1212#c4358 2019-04-11 15:48 geoffclare Status New => Resolved 2019-04-11 15:48 geoffclare Resolution Open => Accepted As Marked 2019-04-11 15:48 geoffclare Tag Attached: issue8 2019-04-15 14:23 chet_ramey Note Added: 0004361 2020-04-27 11:18 geoffclare Status Resolved => Applied ==
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
Robert Elz wrote, on 18 Apr 2019: > > | 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. > > OK, I can accept that, but I differ from you in what "trapped" means. > I know you believe that it means executing the trap command, but there > (also) I disagree. To me a condition is trapped when the condition > arises, and the trap action is executed. That makes no sense in the context of the phrase in the standard, which is "cannot be trapped or reset". Clearly "cannot be reset" is referring to using the trap utility with "-" as the action. So it should be equally clear that the standard is using "cannot be trapped" in reference to use of the trap utility with a command as the action. > But even if that is not what it means, nothing there says that the > shell cannot remember the action that the user wanted to apply to > the condition - the trap might not be set, but the action still remembered. Nonsense. The standard is clearly stating that the trap utility is not allowed to change the action associated with the signal from ignored to default or trapped. > | Executing trap with no > | arguments shows what the current traps are. > > No, it doesn't. We already agreed on the purpose of that, and here > I think things are clear > > The trap command with no operands shall write to standard > output a list of commands associated with each condition. I was using "the current traps" as shorthand for "the list of commands associated with each condition" to save typing. > | If a signal cannot be trapped, then trap with no arguments must > | not show that it is trapped. > > Where is the text that says that? That was a deduction based on the earlier statements I made. There was a clue that I would be making such deductions in my use of the phrase "chain of reasoning". > Further, here, you seem to have changed your earlier position, which > was that it must show that the signal is ignored. Now you're only > requiring must not show that it is trapped, so I assume that you're > now admitting that the shells which output nothing for such a case > (which as we have seen, includes both the initial reference implementations) > are in fact conforming? The above was a deduction early in the "chain of reasoning". You are conflating it with the final conclusion. > | The word "cannot" is simply a contraction of "can not". The word "can" > | is the first entry in XBD 1.5. > > Ah good ... so now we can go on to look at what "can" means, and from > that what its negative would require... > > can > > Describes a permissible optional feature or behavior available to > the user or application. The feature or behavior is mandatory for > an implementation that conforms to POSIX.1-2017. An > application can rely on the existence of the feature or behavior. > > OK, that's simple enough (in the positive) - the application is permitted > to rely upon the existance of the feature, so the implementation must > provide it. > > Now let's examine what the inverse of that is. > > cannnot (or can not, or perhaps even can't) would have to mean > > Describes a feature or behaviour not available to the user or > application. > > Right? So far, yes. > That would imply that there is no requirement on the implementation > to implement that, as the application can not rely upon the existence > of the feature of behaviour. (You can stick a "not" after "is" in > the 2nd sentence to get the same result.) > > Right? Wrong. If the behaviour is not available, that means the implementation must not do what the application asked it to do. If it was only a matter of the application not being able to rely on it, the standard would say "It is unspecified whether ...". > | I can't answer that because I wasn't involved when POSIX.2-1992 was > | developed. > > Perhaps we should ask someone who was We could try, but it was so long ago it is doubtful that anyone would remember this level of detail in one of many discussions. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
Geoff Clare wrote: > Since an attempt to trap such a signal must fail or be silently > ignored, shells in which the following script, when executed with > SIGINT ignored: > > trap some_command INT > trap > > produces output that indicates the action for the INT condition is > some_command clearly do not conform to this requirement. OK, so if I understand you correctly, this means that the original Bourne Shell from 1977 does not conform (even though it did not change the trap setup for ignored signals but prints a change with "trap"), but the SVr2 and newer version are OK, since they do not output anything for "trap" in such a case? Jörg -- EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
Joerg Schilling wrote, on 18 Apr 2019: > > I just discovered a real difference: > > The v7shell and up to the Solaris 10 Bourne sh do not make a difference in > interactive and non-interactive shells and always set up the standard > handlers. > > ksh88, ksh93 and bash do not set up own default handlers for non-interactive > shells. > > Since ksh88 is the first Bourne Shell derivate that is based on malloc() > instead of sbrk(), ksh88 was able to change this. A Bourne Shell that is > based > on sbrk() needs to set up signal handlers before it can do string processing > and before it knows whether it is an interactive shell or a non-interactive > shell. > > What I like to hear from Geoff is whether this difference is required by > POSIX, > since that is not a difference in practice (because the Bourne Shell installs > "done()" that exits for some other signals. It's optional in POSIX. P2420 L77505, "An interactive shell may reset or catch signals ignored on entry." > Given that there was a lot of long mails and a lot of confusion, I would like > to see the basic claims as a full sentence again, to be able to understand > the > different positions. I think I did that in my reply to Thor Lancelot Simon on Tuesday. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
Joerg Schilling wrote: > bash: > SHELL=bash sh test4 > (trap '' INT EMT; $SHELL -c 'trap "" INT; trap - INT; trap; psig $$ | grep > \^INT') > INT caught wait_sigint_handler 0 > (trap '' INT EMT; $SHELL -c 'trap "" INT; trap; psig $$ | grep \^INT') > INT ignored > (trap '' INT EMT; $SHELL -c 'trap "echo foo" INT; trap; psig $$ | grep > \^INT') > INT ignored BTW: ths was bash3, with bash5 you get: SHELL=/tmp/bash\-5.0/bash sh test4 (trap '' INT EMT; $SHELL -c 'trap "" INT; trap - INT; trap; psig $$ | grep \^INT') trap -- '' SIGINT trap -- '' SIGEMT INT caught wait_sigint_handler 0 (trap '' INT EMT; $SHELL -c 'trap "" INT; trap; psig $$ | grep \^INT') trap -- '' SIGINT trap -- '' SIGEMT INT ignored (trap '' INT EMT; $SHELL -c 'trap "echo foo" INT; trap; psig $$ | grep \^INT') trap -- '' SIGINT trap -- '' SIGEMT INT ignored so there is a difference. And as there was a related question from Robert Elz, (trap '' INT; $SHELL -c trap) does not print anything for all shells except for bash5: (trap '' INT; /tmp/bash-5.0/bash -c trap) trap -- '' SIGINT I just discovered a real difference: The v7shell and up to the Solaris 10 Bourne sh do not make a difference in interactive and non-interactive shells and always set up the standard handlers. ksh88, ksh93 and bash do not set up own default handlers for non-interactive shells. Since ksh88 is the first Bourne Shell derivate that is based on malloc() instead of sbrk(), ksh88 was able to change this. A Bourne Shell that is based on sbrk() needs to set up signal handlers before it can do string processing and before it knows whether it is an interactive shell or a non-interactive shell. What I like to hear from Geoff is whether this difference is required by POSIX, since that is not a difference in practice (because the Bourne Shell installs "done()" that exits for some other signals. Given that there was a lot of long mails and a lot of confusion, I would like to see the basic claims as a full sentence again, to be able to understand the different positions. Jörg -- EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
On 4/17/19 12:45 PM, Robert Elz wrote: > Date:Wed, 17 Apr 2019 11:51:17 -0400 > From:Chet Ramey > Message-ID: > > | But that's not what I'm claiming. I'm observing that the behavior you > | cited from the historical Bourne shell, the option you said Geoff forgot, > | is not present in either of the reference implementations. As such, it > | doesn't much matter, and isn't what the standard is suggesting is > | conformant. > > Oh, I see I am (as usual) apparently not being very clear. > > My position is that the standard says nothing at all about what > should be output for a trap that was ignored in a non-interactive > shell at startup, when the "trap" command is given later. I'm still going to let Geoff defend his position, since the debate so far has mostly been about different positions about what the standard says. My point here is that it doesn't matter what the historical Bourne shell did. The debate should be why the standard (apparently) departed from the reference implementations' behavior. (And it did that early on; the language about interactive shells being able to trap signals ignored on shell startup was in the very early drafts.) -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Fwd: Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
--- Begin Message --- Date:Wed, 17 Apr 2019 11:51:17 -0400 From:Chet Ramey Message-ID: | But that's not what I'm claiming. I'm observing that the behavior you | cited from the historical Bourne shell, the option you said Geoff forgot, | is not present in either of the reference implementations. As such, it | doesn't much matter, and isn't what the standard is suggesting is | conformant. Oh, I see I am (as usual) apparently not being very clear. My position is that the standard says nothing at all about what should be output for a trap that was ignored in a non-interactive shell at startup, when the "trap" command is given later. That is, any of the three outputs that we have seen is OK, the modern bash version, the ash (and ancient Bourne shell version, with the formatting corrected anyway) or the ksh88/solaris10 (SYSVR4.2) (ad mksh, etc) shell's forms. That's actually reasonable, if we accept that the point of the trap command is to allow the trap state to be saved, so it can be restored (which is the example that the standard does give.) In that case, if a signal was ignored on entry to the shell, then it is still ignored when we to the eval "$saved_traps" command that uses the output of an earlier saved_traps=$(trap) In that case it doesn't matter what saved_traps contains about the ignored signal (including nothing) since the signal will remain ignored anyway. The fanciful interlude that we had about long running scripts, and checkpoints, and restarts, was really just a day dream. The chances of a shell script ever reliably working with a model like that (regardless of anything related to traps) are vanishingly small - that we have to dream up nonsense possible applications to talk about this is largely because there are no real ones (certainly none I have ever heard of). My objection is to the claim that the standard does actually mandate what should be output in this case, and picks one of the three reasonable forms to be it (which happens to be the modern bash form.) kre --- End Message ---
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
On 4/17/19 11:37 AM, Robert Elz wrote: > Date:Wed, 17 Apr 2019 11:05:28 -0400 > From:Chet Ramey > Message-ID: > > | The two historical reference implementations are the SVR4 Bourne shell > | and ksh88. What the Bourne shell did in 1978 is not as important as what > | these two shells did in 1988. > > I have no problem with that (the 1978 Bourne shell was kind of primitive, > as Joerg's recent testing illustrates...) > > | Neither of the two reference implementations seem to have done that, > | regardless of what the original Bourne shell did. > > Perhaps not, but nor did they, as best I can tell from your and Joerg's > testing, output an invented trap command (the way modern bash does) to > indicate that a signal was ignored on entry to the shell. But that's not what I'm claiming. I'm observing that the behavior you cited from the historical Bourne shell, the option you said Geoff forgot, is not present in either of the reference implementations. As such, it doesn't much matter, and isn't what the standard is suggesting is conformant. I'll let Geoff defend his position about what the standard does require. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
Date:Wed, 17 Apr 2019 11:05:28 -0400 From:Chet Ramey Message-ID: | The two historical reference implementations are the SVR4 Bourne shell | and ksh88. What the Bourne shell did in 1978 is not as important as what | these two shells did in 1988. I have no problem with that (the 1978 Bourne shell was kind of primitive, as Joerg's recent testing illustrates...) | Neither of the two reference implementations seem to have done that, | regardless of what the original Bourne shell did. Perhaps not, but nor did they, as best I can tell from your and Joerg's testing, output an invented trap command (the way modern bash does) to indicate that a signal was ignored on entry to the shell. It is that behaviour, which is claimed to be required, that I am disputing. Ie: that is the content of the clause in parentheses that is proposed to be added to the wording of the "trap" command without any args (and is claimed to be just a clarification.) I don't care whether the shell simlpy ignores a trap command when the signal was ignored when the shell started (the way that those shells, and several since, seem to do) or whether it saves the trap action and outputs that, but still doesn't change the signal disposition (the very ancient Bourne shell behaviour, and ash derived shells, maybe some others) (though I really belive that the latter is the best behaviour, and if the standard eventuially changes to make that invalid, I will certainly add an option to enable that form). The primary test for me is (trap '' INT; $SHELL -c trap) shells (of 1992 vintage) which output trap -- '' INT (or anything more or less equivalent) would be interesing to learn about. Any single instance (from that period) would be truly remarkable to find. Because, so we are being told, in 1992, the standard required that. Even today, only bash (of all shells I can find to test) does it that way. kre
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
On 4/17/19 11:12 AM, Joerg Schilling wrote: >>> Could you explain what kind of shell you have in the binary file "sh4.2"? >> >> It's the shell from SVR4.2. > > Could you be a bit more explicit please? How much more explicit do you want me to be? It's a Mac OS X binary built from the sh source code distributed as part of the SVR4.2 source distribution from 1994. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
Chet Ramey wrote: > On 4/17/19 11:02 AM, Joerg Schilling wrote: > > Chet Ramey wrote: > > > >> $ cat xtrap1 > >> (trap '' SIGINT; $SHELL -c 'trap some_command SIGINT ; trap' ) > >> $ SHELL=sh4.2 sh4.2 xtrap1 > >> $ > >> > >> Someone with Solaris can probably say what the SVR4 shell does, at least > >> as it appears there. Maybe the bosh output is enough. > > > > Could you explain what kind of shell you have in the binary file "sh4.2"? > > It's the shell from SVR4.2. Could you be a bit more explicit please? I am asking this because many people claim to use the svr4 shell when they run the so called "heirloom" shell that is not useful for reference tests. Jörg -- EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
On 4/17/19 11:02 AM, Joerg Schilling wrote: > Chet Ramey wrote: > >> $ cat xtrap1 >> (trap '' SIGINT; $SHELL -c 'trap some_command SIGINT ; trap' ) >> $ SHELL=sh4.2 sh4.2 xtrap1 >> $ >> >> Someone with Solaris can probably say what the SVR4 shell does, at least >> as it appears there. Maybe the bosh output is enough. > > Could you explain what kind of shell you have in the binary file "sh4.2"? It's the shell from SVR4.2. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
OK, it seems that I need to correct the script for the v7 shell, since that shell does not only not understand "INT" but also does not grok "-" So the correct results are: SHELL=v7sh sh test3 (trap '' INT EMT; $SHELL -c 'trap "" 2; trap 2; trap; psig $$ | grep \^INT') INT ignored (trap '' INT EMT; $SHELL -c 'trap "" 2; trap; psig $$ | grep \^INT') 2: INT ignored (trap '' INT EMT; $SHELL -c 'trap "echo foo" 2; trap; psig $$ | grep \^INT') 2: echo foo INT ignored Jörg -- EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
On 4/17/19 10:25 AM, Robert Elz wrote: > Date:Wed, 17 Apr 2019 09:40:01 +0100 > From:Geoff Clare > Message-ID: <20190417084001.GA26431@lt2.masqnet> > > | You make it sound like we are deliberately changing the standard to > | disallow historical behaviour. That's not what's happening. > > But it is. It seems like this is the crux of it. The two historical reference implementations are the SVR4 Bourne shell and ksh88. What the Bourne shell did in 1978 is not as important as what these two shells did in 1988. > 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. > > which is what the original Bourne shell did, and which has been > copied by other shells, though some have adopted your 2nd possibility > and simply ignore the trap command in this case. Neither of the two reference implementations seem to have done that, regardless of what the original Bourne shell did. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
Chet Ramey wrote: > $ cat xtrap1 > (trap '' SIGINT; $SHELL -c 'trap some_command SIGINT ; trap' ) > $ SHELL=sh4.2 sh4.2 xtrap1 > $ > > Someone with Solaris can probably say what the SVR4 shell does, at least > as it appears there. Maybe the bosh output is enough. Could you explain what kind of shell you have in the binary file "sh4.2"? Jörg -- EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
Robert Elz wrote: > Date:Wed, 17 Apr 2019 11:35:18 +0200 > From:Joerg Schilling > Message-ID: > <5cb6f356.dh4k5z2xfkptm0+v%joerg.schill...@fokus.fraunhofer.de> > > > | If the standard did require something that is neither covered by the > | historical Bourne Shell behavior > > We know the historical Bourne shell output the trap that was set > by the user, regardless of whether that resulted in a signal being > caught, or not because the signal was ignored on entry to the shell. > I showed the code that did that in an earlier message. Theere is a difference between the historic Bourne Shell from SVr2 (1983) and the one from 1977, but only with regard to what is printed from "trap". V7: SHELL=shells/v7/sh sh test (trap '' INT EMT; $SHELL -c 'trap "" INT; trap - INT; trap') shells/v7/sh: INT: bad number (trap '' INT EMT; $SHELL -c 'trap "" INT; trap') shells/v7/sh: INT: bad number (trap '' INT EMT; $SHELL -c 'trap "echo foo" INT; trap') shells/v7/sh: INT: bad number SHELL=shells/v7/sh sh test2 (trap '' 2 EMT; $SHELL -c 'trap "" 2; trap - 2; trap') 2: - (trap '' 2 EMT; $SHELL -c 'trap "" 2; trap') 2: (trap '' 2 EMT; $SHELL -c 'trap "echo foo" 2; trap') 2: echo foo SVr4: SHELL=sh sh test (trap '' INT EMT; $SHELL -c 'trap "" INT; trap - INT; trap') (trap '' INT EMT; $SHELL -c 'trap "" INT; trap') (trap '' INT EMT; $SHELL -c 'trap "echo foo" INT; trap') ksh88: SHELL=ksh sh test (trap '' INT EMT; $SHELL -c 'trap "" INT; trap - INT; trap') (trap '' INT EMT; $SHELL -c 'trap "" INT; trap') trap -- '' INT (trap '' INT EMT; $SHELL -c 'trap "echo foo" INT; trap') trap -- 'echo foo' INT ksh93: SHELL=ksh93 sh test (trap '' INT EMT; $SHELL -c 'trap "" INT; trap - INT; trap') trap -- '' INT (trap '' INT EMT; $SHELL -c 'trap "" INT; trap') trap -- '' INT (trap '' INT EMT; $SHELL -c 'trap "echo foo" INT; trap') trap -- 'echo foo' INT bosh: SHELL=bosh sh test (trap '' INT EMT; $SHELL -c 'trap "" INT; trap - INT; trap') (trap '' INT EMT; $SHELL -c 'trap "" INT; trap') (trap '' INT EMT; $SHELL -c 'trap "echo foo" INT; trap') bash: SHELL=bash sh test (trap '' INT EMT; $SHELL -c 'trap "" INT; trap - INT; trap') (trap '' INT EMT; $SHELL -c 'trap "" INT; trap') (trap '' INT EMT; $SHELL -c 'trap "echo foo" INT; trap') If you like to check what really happens, you would need to use psig(1)... V7: SHELL=shells/v7/sh sh test3 (trap '' INT EMT; $SHELL -c 'trap "" 2; trap - 2; trap; psig $$ | grep \^INT') 2: - INT ignored (trap '' INT EMT; $SHELL -c 'trap "" 2; trap; psig $$ | grep \^INT') 2: INT ignored (trap '' INT EMT; $SHELL -c 'trap "echo foo" 2; trap; psig $$ | grep \^INT') 2: echo foo INT ignored SVr4: SHELL=sh sh test4 (trap '' INT EMT; $SHELL -c 'trap "" INT; trap - INT; trap; psig $$ | grep \^INT') INT ignored (trap '' INT EMT; $SHELL -c 'trap "" INT; trap; psig $$ | grep \^INT') INT ignored (trap '' INT EMT; $SHELL -c 'trap "echo foo" INT; trap; psig $$ | grep \^INT') INT ignored ksh88: SHELL=ksh sh test4 (trap '' INT EMT; $SHELL -c 'trap "" INT; trap - INT; trap; psig $$ | grep \^INT') INT ignored (trap '' INT EMT; $SHELL -c 'trap "" INT; trap; psig $$ | grep \^INT') trap -- '' INT INT ignored (trap '' INT EMT; $SHELL -c 'trap "echo foo" INT; trap; psig $$ | grep \^INT') trap -- 'echo foo' INT INT ignored ksh93: SHELL=ksh93 sh test4 (trap '' INT EMT; $SHELL -c 'trap "" INT; trap - INT; trap; psig $$ | grep \^INT') trap -- '' INT INT ignored (trap '' INT EMT; $SHELL -c 'trap "" INT; trap; psig $$ | grep \^INT') trap -- '' INT INT ignored (trap '' INT EMT; $SHELL -c 'trap "echo foo" INT; trap; psig $$ | grep \^INT') trap -- 'echo foo' INT INT ignored bosh: SHELL=bosh sh test4 (trap '' INT EMT; $SHELL -c 'trap "" INT; trap - INT; trap; psig $$ | grep \^INT') INT ignored (trap '' INT EMT; $SHELL -c 'trap "" INT; trap; psig $$ | grep \^INT') INT ignored (trap '' INT EMT; $SHELL -c 'trap "echo foo" INT; trap; psig $$ | grep \^INT') INT ignored dash: SHELL=dash sh test4 (trap '' INT EMT; $SHELL -c 'trap "" INT; trap - INT; trap; psig $$ | grep \^INT') INT ignored (trap '' INT EMT; $SHELL -c 'trap "" INT; trap; psig $$ | grep \^INT') trap -- '' INT INT ignored (trap '' INT EMT; $SHELL -c 'trap "echo foo" INT; trap; psig $$ | grep \^INT') trap -- 'echo foo' INT INT ignored bash: SHELL=bash sh test4 (trap '' INT EMT; $SHELL -c 'trap "" INT; trap - INT; trap; psig $$ | grep \^INT') INT caught wait_sigint_handler 0 (trap '' INT EMT; $SHELL -c 'trap "" INT; trap; psig $$ | grep \^INT') INT ignored (trap '' INT EMT; $SHELL -c 'trap "echo foo" INT; trap; psig $$ | grep \^INT') INT ignored zsh: SHELL=zsh sh test4 (trap '' INT EMT; $SHELL -c 'trap "" INT; trap - INT; trap; psig $$ | grep \^INT') INT default (trap '' INT EMT; $SHELL -c 'trap "" INT; trap; psig $$ | grep \^INT') trap -- '' INT INT ignored (trap '' INT EMT; $SHELL -c 'trap "echo
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
On 4/17/19 9:45 AM, Robert Elz wrote: > Date:Wed, 17 Apr 2019 11:35:18 +0200 > From:Joerg Schilling > Message-ID: > <5cb6f356.dh4k5z2xfkptm0+v%joerg.schill...@fokus.fraunhofer.de> > > > | If the standard did require something that is neither covered by the > | historical Bourne Shell behavior > > We know the historical Bourne shell output the trap that was set > by the user, regardless of whether that resulted in a signal being > caught, or not because the signal was ignored on entry to the shell. > I showed the code that did that in an earlier message. That must have changed by the SVR4 shell, which was one of the reference implementations for the standard. By the time SVR4.2 rolled around, it definitely printed nothing: $ cat xtrap1 (trap '' SIGINT; $SHELL -c 'trap some_command SIGINT ; trap' ) $ SHELL=sh4.2 sh4.2 xtrap1 $ Someone with Solaris can probably say what the SVR4 shell does, at least as it appears there. Maybe the bosh output is enough. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
Date:Wed, 17 Apr 2019 09:40:01 +0100 From:Geoff Clare Message-ID: <20190417084001.GA26431@lt2.masqnet> | You make it sound like we are deliberately changing the standard to | disallow historical behaviour. That's not what's happening. But it is. | We are upholding a requirement that has been in the standard since 1992, But it hasn't. I suspect somewhere, somehow, you simply cannot believe that the standard allows (if not more than that) the behaviour of every (so far tested) shell other than bash - and because of that you are forcing yourself to read the words as if they say something that is simply not there. That's why you find youself needing to add "clarifying" text to "make it clear" - whereas in reality, the reason it wasn't obvious before is that the requirement was not there before. This is independent of what the ideal behaviour would be, just what the standard actually says, from forever in the past, until now. | 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. which is what the original Bourne shell did, and which has been copied by other shells, though some have adopted your 2nd possibility and simply ignore the trap command in this case. | 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. | 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. And again, your are confusing the signal state with the shell trap state, the two are (quite often) not the same. | 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) and why is there not a single example in the application usage on this point? My answer would be because they did not believe the wording they were writing was any different from what shells at the time actually did (this was an area of general agreement) and so there was no change to explain, and since everyone was doing what was required, and it was familiar, and simple enough, there was no need for an example either. kre
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
On 4/17/19 5:35 AM, Joerg Schilling wrote: > Geoff Clare wrote: > >> 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". 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, or for it to exit with status 0 without >> changing the action for the INT condition. >> >> Since an attempt to trap such a signal must fail or be silently >> ignored, shells in which the following script, when executed with >> SIGINT ignored: >> >> trap some_command INT >> trap >> >> produces output that indicates the action for the INT condition is >> some_command clearly do not conform to this requirement. > > Given that this _is_ the historical behavior, I see no problem with this > requirement. This is where the behavior varies. I described the variation in a previous message. Even `conformant' shells vary. > If the standard did require something that is neither covered by the > historical > Bourne Shell behavior nor ksh88 and that is not clearly verified to fix a > bug, > there of course was a problem. Given that interpretation, the only variance from historical behavior is the standard allowing interactive shells to reset the disposition of signals that were ignored at shell entry. That language was in the standard from the earliest drafts -- probably by 1003.2 draft 9, and certainly by draft 11. There's nothing in the early rationales about it. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
Date:Wed, 17 Apr 2019 11:35:18 +0200 From:Joerg Schilling Message-ID: <5cb6f356.dh4k5z2xfkptm0+v%joerg.schill...@fokus.fraunhofer.de> | If the standard did require something that is neither covered by the | historical Bourne Shell behavior We know the historical Bourne shell output the trap that was set by the user, regardless of whether that resulted in a signal being caught, or not because the signal was ignored on entry to the shell. I showed the code that did that in an earlier message. | nor ksh88 I don't have access to ksh88 to test it, but something tells me that if it did what it is claimed the standard requires, we would have been told about it by now. ksh93 doesn't... ksh93 $ (trap '' INT EMT; ksh93 -c trap) ksh93 $ What ksh93 does do however, is that if an attempt is made to trap a signal, and that doesn't result in changing the signal disposition, then after that the trap command tells you the signal is ignored... ksh93 $ (trap '' INT EMT; ksh93 -c 'trap "echo foo" INT; trap') trap -- '' INT ksh93 $ But that only happens if a trap action is set (or, obviously, if the script requests to ignore the signal) If the script requests to reset the signal to default, we're back to no output ksh93 $ (trap '' INT EMT; ksh93 -c 'trap - INT; trap') ksh93 $ That is, unless it was first set to some other state: ksh93 $ (trap '' INT EMT; ksh93 -c 'trap "" INT; trap - INT; trap') trap -- '' INT ksh93 $ (trap '' INT EMT; ksh93 -c 'trap "echo foo" INT; trap - INT; trap') trap -- '' INT All that mess just looks like bugs in ksh93 to me... yash and bosh seem to completely ignore any attempt to trap a signal that's ignored at startup (in a non-interactive shell - all these tests test non-interactive shells). bosh $ (trap '' INT EMT; $SHELL -c 'trap "" INT; trap - INT; trap') bosh $ (trap '' INT EMT; $SHELL -c 'trap "" INT; trap') bosh $ (trap '' INT EMT; $SHELL -c 'trap "echo foo" INT; trap') bosh $ (if the signal was not inored, the right thing happens) yash $ (trap '' INT EMT; $SHELL -c 'trap "" INT; trap - INT; trap') yash $ (trap '' INT EMT; $SHELL -c 'trap "" INT; trap') yash $ (trap '' INT EMT; $SHELL -c 'trap "echo foo" INT; trap') yash $ old pdksh and mksh both do ... mksh $ (trap '' INT EMT; $SHELL -c 'trap "" INT; trap - INT; trap') mksh $ (trap '' INT EMT; $SHELL -c 'trap "" INT; trap') trap -- INT mksh $ (trap '' INT EMT; $SHELL -c 'trap "echo foo" INT; trap') trap -- 'echo foo' INT mksh $ Pity about the lack of quoting around the null string action in the middle example ... but if I was forced to guess, I'd tend to assume that ksh88 probably acts that way as well (perhaps even including the missing explicit null string). I am not sure what happens exactly with zsh (what is going on) I don't usually use it, and don't understand all of its variations, but in that one I need to send an extra newline, otherwise it simply sits and waits forever... But with that newline: zsh $ (trap '' INT EMT; $SHELL -c 'trap "" INT; trap - INT; trap') zsh $ (trap '' INT EMT; $SHELL -c 'trap "" INT; trap') trap -- '' INT zsh $ (trap '' INT EMT; $SHELL -c 'trap "echo foo" INT; trap') trap -- 'echo foo' INT zsh $ The shell I generally regard as the most standards conforming of all I have seen (certainly more than its close relative, the NetBSD sh) that is, the FreeBSD shell (it seems like any time they find anytging that is different than the standard requires, they change it) does fbsh $ (trap '' INT EMT; $SHELL -c 'trap "" INT; trap - INT; trap') fbsh $ (trap '' INT EMT; $SHELL -c 'trap "" INT; trap') trap -- '' INT fbsh $ (trap '' INT EMT; $SHELL -c 'trap "echo foo" INT; trap') trap -- 'echo foo' INT fbsh $ bash is the one that is notably different... bash $ (trap '' INT EMT; $SHELL -c 'trap "" INT; trap - INT; trap') trap -- '' SIGINT trap -- '' SIGEMT bash $ (trap '' INT EMT; $SHELL -c 'trap "" INT; trap') trap -- '' SIGINT trap -- '' SIGEMT bash $ (trap '' INT EMT; $SHELL -c 'trap "echo foo" INT; trap') trap -- '' SIGINT trap -- '' SIGEMT bash $ (In each of these, $SHELL is the shell indicated by the PS1 output). kre
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
Date:Tue, 16 Apr 2019 16:17:43 +0100 From:Geoff Clare Message-ID: <20190416151743.GA19870@lt2.masqnet> | I'm sure we haven't tested every shell, so it's impossible to | answer that. Is there any shell you know of, other than bash, that acts as you claim all shells are required to act?How many systems have been certified POSIX conformant with a shell that does not act that way? | That's a good argument for changing the standard to disallow an error. | However, it's a separate issue and doesn't really affect the main issue | we are discussing. I agree with the latter. For the former, these days, there's a good argument for deleting the exception - to simply allow any shell to set any possible trap, anytime (this certainly would be a change to the standard - we could discuss this some other time perhaps.) | You would need: | | action=' | trap -- "" INT | ' Good catch, yet. | But I take your point - such simple parsing methods are not 100% reliable. They're not. | However, you had to construct a particularly pathological example in order | to defeat my ERE. No, that one was just slightly weird. Much worse possibilities are possible. This is a side issue however, not really germane to the discussion. Further, with trap -p this all becomes much easier, as one can now request the state of a single signal's trap command, and when you know there is exactly one, parsing it becomes something within the abilities of any mildly competent shell programmer. That this is (will be) possible now, is one of the reasons why it would become safe to allow any (trappable) signal to be trapped, in all circumstances - just like C programs can. | I assume you meant set +m here. Yes, of course, sorry... | As with parsing by ERE, you have carefully constructed an example that | supports your position. But naturally, I am hardly going to construct an example that doesn't, am I? But this kind of thing is real, if an application is trapping a signal, it wants it trapped. That's why the code is there. Sometimes that is not possible, but that doesn't matter, as in those cirsumstances the signal can never be delivered. But when it is possible, it should always be pemitted - not refused because when the application started, days or weeks ago, the trap didn't work, so that obviously means that you can't have it now either. | One case could be if delivery of the signal causes something to be | logged. It would be desirable to have consistent logging based on | the signal disposition when the task was originally started, I fail to see why - when it started, no signals were received, so no logging happened. Does it really matter why? After the restart signals can be received, if one is, surely the logging should happen then. I know that's what I would want. | > That is, for either method, things work for this kind of usage. Neither | > is "simply wrong". | | In which case I don't see the point of including that lengthy example in | your (already extremely long) email. Perhaps - but I felt it important to show that in the common case, it makes no difference which way things work. That is, doing it the way most shells have always done it, is perfectly safe, not "simply wrong". | Because you carefully chose an example where that would happen. Of course. But there should be no such cases, things should be consistent. | There was general agreement on the teleconference that having the trap | output reflect what the shell will actually do is the right behaviour | to specify. You seem to be a lone voice of dissent. I am not sure even I dissent, as I said in the original message, if we want that to happen, if that really is the best outcome, then we can do that. But what I insist upon is that we are aware that we are deliberately changing things, this is not just restating what the standard always said (nor would it rationally in the past have ever said that, and certainly not without a rationale to explain why the change was made from traditional behaviour.) kre
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
Geoff Clare wrote: > 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". 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, or for it to exit with status 0 without > changing the action for the INT condition. > > Since an attempt to trap such a signal must fail or be silently > ignored, shells in which the following script, when executed with > SIGINT ignored: > > trap some_command INT > trap > > produces output that indicates the action for the INT condition is > some_command clearly do not conform to this requirement. Given that this _is_ the historical behavior, I see no problem with this requirement. If the standard did require something that is neither covered by the historical Bourne Shell behavior nor ksh88 and that is not clearly verified to fix a bug, there of course was a problem. Jörg -- EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
Thor Lancelot Simon wrote, on 16 Apr 2019: > > On Tue, Apr 16, 2019 at 04:17:43PM +0100, Geoff Clare wrote: > > > > There was general agreement on the teleconference that having the trap > > output reflect what the shell will actually do is the right behaviour > > to specify. You seem to be a lone voice of dissent. > > For what it's worth, I agree with Bob on this. Abandoning the historical > behavior to match bash is not the right thing (in this case and generally > not in others). You make it sound like we are deliberately changing the standard to disallow historical behaviour. That's not what's happening. We are upholding a requirement that has been in the standard since 1992, and the other changes are a natural consequence of that (plus the changes to add the new -p option). 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". 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, or for it to exit with status 0 without changing the action for the INT condition. Since an attempt to trap such a signal must fail or be silently ignored, shells in which the following script, when executed with SIGINT ignored: trap some_command INT trap produces output that indicates the action for the INT condition is some_command clearly do not conform to this requirement. Likewise, since an attempt to reset such a signal to default must fail or be silently ignored, if the script is: trap "" INT trap - INT trap shells which produce output (or lack of it) that indicates the default action for INT clearly do not conform. Slightly less clear, but given the above it is the only behaviour that makes sense, is if the script is just: trap - INT trap or just: trap then the script should not produce output (or lack of it) that indicates the default action for INT. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
Note that I've deleted most of the quoted email because it was just
going round the same arguments in a "yes it does" ... "no it doesn't"
pantomime fashion. I'm only responding to the parts that are
genuinely new.
Robert Elz wrote, on 16 Apr 2019:
>
> | The reason for the addition is because some shells do not include the
> | signals that were ignored on entry to a non-interactive shell in the
> output.
>
> By "some shells" you mean "all shells except bash", right...
I'm sure we haven't tested every shell, so it's impossible to
answer that.
> It also says that there isn't likely to be an error. I don't know
> about you, but if I do operation X, and it is accepted without any
> kind of error message/status, I expect it to have been performed. Not
> ignored.
Since we are in the realms of signals, here are some pertinent quotes
from the sigaction() page:
The SIGKILL and SIGSTOP signals shall not be added to the signal
mask using this mechanism; this restriction shall be enforced by
the system without causing an error to be indicated.
SIGILL and SIGTRAP cannot be automatically reset when delivered;
the system silently enforces this restriction.
and the sigprocmask() page:
It is not possible to block those signals which cannot be ignored.
This shall be enforced by the system without causing an error to
be indicated.
So there is certainly precedent for POSIX requiring that some actions
are simply ignored without causing an error.
> | My guess is that the authors of POSIX.2-1992 would have liked to mandate
> | an error as that would be highly desirable, but felt they had to make it
> | optional because of existing practice.
>
> That they were shy about, this minor point, but they were willing to
> change the existing practice of how the trap command worked, and had
> always worked, with no clear language, no rationale, and no example
> to illustrate it?
Fair point. My guess may well be wrong.
> The reason that there is no error (why no-one outputs an error, and never
> will) is that scripts do things like
>
> trap 'something' INT
>
> (where the "something" might be nothing, to ignore SIGINT) If an error
> were generated because the script was run in background, which meant that
> SIGINT started ignored, then the script users would lynch the shell author.
That's a good argument for changing the standard to disallow an error.
However, it's a separate issue and doesn't really affect the main issue
we are discussing.
> | Why do you say parsing the output is nearly impossible? The format is
> | clearly specified:
> |
> | "trap -- %s %s ...\n", , ...
> |
> | with "proper use of quoting".
> |
> | If a signal is being ignored, is a (quoted) empty string, so
> | the output is going to match the ERE:
> |
> | ^trap[[:blank:]]+--[[:blank:]]+(""|'')[[:blank:]]
>
> Yes, you'd think so, now consider
>
> action='
> trap "" INT
> '
> and then execute
>
> trap "$action" HUP
>
> and now the "trap" command, and use your ERE to tell me what the
> state of the INT trap is?
With the exact code in your example, the ERE would give the right
answer. You would need:
action='
trap -- "" INT
'
to fool it.
But I take your point - such simple parsing methods are not 100% reliable.
However, you had to construct a particularly pathological example in order
to defeat my ERE. In real life it's extremely unlikely to give the wrong
answer, particularly since the trap actions in the output will have been
set in the application doing the parsing. If the application writer knows
they will be parsing the output with an ERE, they will either avoid using
multi-line actions, or at least avoid ones that have a line beginning
"trap -- ".
> | Normally the reinput is to the same running shell, but there is no
> | reason it can't be a different instance of "the shell" (i.e. the "sh"
> | that PATH finds). (Imagine some long-running task that can be
> | checkpointed and later restarted from a checkpoint.) If the output is
> | from a shell that had some signals ignored on entry, and the shell
> | where that output is reinput does not, then the signal dispositions
> | will not match.
>
> Everything there I agree with, except your unstated conclusion that this
> is a bad thing. That is (this is irrelevant for our general discussion)
> everything there except possibly for:
>
> | but there is no reason it can't be a different instance of "the shell"
>
> A different instance, yes, that's OK, but it has to be running the same
> script I think, not just be output from bosh input to a different bosh
> shell process (or pick any other that you like for this).
>
> Otherwise when I do
>
> trap myfunc SIGX
>
> and later trap outputs
>
> trap -- myfunc SIGX
>
> if "myfunc" doesn't exist as a function in the shell that rereads that
> then we have not reestablished the same trap state.
Yes we have. The trap
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
Date:Tue, 16 Apr 2019 09:29:09 +0100 From:Geoff Clare Message-ID: <20190416082909.GB18055@lt2.masqnet> | "except commands that have changed the state" is precisely the point. I agree. The question though is which state. | In the context we are discussing, the standard requires that for | interactive shells it changes the state and for non-interactive shells | it does not. You're assuming that it is the signal state (as in how things are set in the kernel) - whereas I believe it means the shell's trap state. Further I don't believe that the standard prohibits changing anything, what it says is that for a non-interactive shell, a signal that was ignored on input cannot be trapped, which I read as saying that for such a signal, the trap which is set will never be executed. If it had meant what you believe, there are far easier ways of saying so. | I'm talking about the behaviour the standard requires, not about | historical practice. I understand that, though the standard (usually) requires at least something similar to the latter, and when it doesn't it says exactly why. Where is the rationale for this apparent deviation from previously accepted behaviour? | Signals are a subset of traps. Signals are a kernel/application interface. traps are a shell/script interface. Some signals cannot be traps, and as you say, there are some traps that are not signals. Signals are the lower level mechanism that the shell uses to (help) implement some of the traps. | I strongly disagree. If a signal will be ignored but trap with no | operands says otherwise, that is simply incorrect information and | should be considered to be a bug. Again, this depends upon your view of the point of the trap command. As it was in the Bourne shell, it was information for users - the output was useless for anything else, and at that time you might have had a point (though I would still argue). But when a change was needed, rather than requiring that the trap output should match the kernel signal state (which could have been done) the change that was made was to convert the trap output format so that it is useful for the shell. For that, the state of the kernel interface is irrelevant. | The reason for the addition is because some shells do not include the | signals that were ignored on entry to a non-interactive shell in the output. By "some shells" you mean "all shells except bash", right... | Clearly the authors of those shells did not realise that the standard | requires that they are output, Because it never did. They were all correct. There have been several shells written based primarily upon what the standard says - only bash seems to have decided that the words mean what you say. My conclusion from that is that they do not. | and so it is worth pointing it out. Which would be changing the standard to alter what it requires. That's something that can be discussed - I'm not sure there is any great value in it, and there is some harm, but it still might be an acceptable approach. But it would be a change. | Of course. The first quote is a general rule, and the third is an | exception to that rule. I disagree. That is simply a statement of what can be expected to happen, not a requirement on the shell, which would require wording like "shall..." which it doesn't have. All it is doing is informing readers (and implementors) that if in a non-interactive shell a signal was ignored when the shell started, then it must remain ignored (which was a requirement to make non-job-control background processes sane). It does not say more than that. It also says that there isn't likely to be an error. I don't know about you, but if I do operation X, and it is accepted without any kind of error message/status, I expect it to have been performed. Not ignored. In this case we know that the kernel signal state doesn't get altered, so what other thing is being performed? My answer would be saving the trap in the shell's list of conditions/actions. And then if it is there, reporting it when asked for a list of all of those. That's what was always done historically, it is an entirely reasonable state to have (it really is *not* broken), so without compelling, explicit, evidence to the contrary, I simply cannot believe that it is or ever was, intended to be different. | My guess is that the authors of POSIX.2-1992 would have liked to mandate | an error as that would be highly desirable, but felt they had to make it | optional because of existing practice. That they were shy about, this minor point, but they were willing to change the existing practice of how the trap command worked, and had always worked, with no clear language, no rationale, and no example to illustrate it? Really? Do you have any bridges for sale? The reason that there is no error (why no-one outputs an error, and never will) is that scripts do things like
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
Robert Elz wrote, on 16 Apr 2019:
>
> g...@opengroup.org quoted me, and said:
> | > Huh? What "trap - $sig" ?
> | The one three lines above that in my email. (Which is now below, because
> of
> | your reordering.)
>
> Yes, that I assumed. The point was more what that has to do with
> anything. The question is what "trap" should output. That cannot
> depend upon what other commands might perhaps be, or have been issued
> earlier (except commands that have changed the state).
"except commands that have changed the state" is precisely the point.
In the context we are discussing, the standard requires that for
interactive shells it changes the state and for non-interactive shells
it does not.
> | 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.
>
> I have never believed that to be true
I'm talking about the behaviour the standard requires, not about
historical practice.
> Part of the division between views of this, I think, is that I (at least)
> view traps and signals as different things (and I think the diffeence in
> names supports that - the command could have been called sig or signal or
> something after all).
>
> Signals are simply the underlying kernel mechanism that allows traps to
> be implemented.
Signals are a subset of traps. (The complement of the subset being EXIT
in the standard; ksh also has an ERR trap.)
> The "reveal the state of the kernel interface model" is not really very
> useful.
I strongly disagree. If a signal will be ignored but trap with no
operands says otherwise, that is simply incorrect information and
should be considered to be a bug.
> | 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
>
> because for the purposes of the trap command, as long as it remains
> the way you want it to be, there is nothing special. What you want
> is for it to write out the state of the kernel sigaction - if it is
> SIG_DFL, then "trap" says nothing, if it is SIG_IGN, then "trap" says
> the action is an empty string, and if it is something else, then we
> report that action string that has been set.
>
> Whether the shell is interactive or not, whether the signal is in SIG_IGN
> state because of a previous trap command, or because it started out that
> way, makes no difference whatever. Don't complicate things.
The reason for the addition is because some shells do not include the
signals that were ignored on entry to a non-interactive shell in the output.
Clearly the authors of those shells did not realise that the standard
requires that they are output, and so it is worth pointing it out.
>| The behaviour of these shells also doesn't conform to the requirements
>| of the current standard.
>
> I disagree.
>
> Lines 77490-2
> If action is '-', the shell shall reset each condition to the
> default value. If action is null (""), the shell shall ignore
> each specified condition if it arises. Otherwise, the argument
> action shall be read and executed by the shell when one of the
> corresponding conditions arises.
>
> Lines 77514-5
> The trap command with no operands shall write to standard output
> a list of commands associated with each condition.
>
> To me that's clear. The trap command (with args) sets an action for
> when (if) a condition arises, and without args lt lists the commands for
> each condition. Nothing there about inventing different conditions
> that what was set. And certainly nothing about writing the "ignored"
> output state for traps that will not be delivered to the shell.
>
> I suspect that you're relying upon line 77504
>Signals that were ignored on entry to a non-interactive shell
>cannot be trapped or reset,
Of course. The first quote is a general rule, and the third is an
exception to that rule.
> but (to me) that is just saying that the signal (not the trap) cannot be
> altered in the circumstance. Note "signals" not "conditions" used
> elsewhere (though I know the latter is partly because of EXIT, which
> is not a signal, and obviously cannot be ignored when the shell starts...)
It is not "partly" because of EXIT; that *is* the reason. When "condition"
is used it can be a signal or EXIT, when "signal" is used it cannot be
EXIT.
> I believe a perfectly valid interpretation of what has been there (before
> this new wording in 1212) is that the traps can be set, and later displayed,
> regardless of the state of the signals at entry, all that the latter affects
> is which signals can be delivered to the shell to cause the trap action to
> be invoked.
>
> | The standard clearly states that signals ignored on entry to a
> | non-interactive shell *cannot* be trapped or reset.
>
> Yes,
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
On 4/15/19 1:07 PM, Robert Elz wrote: > chet.ra...@case.edu said in yet another message: > | OK, then there must be some other reason that text appears in the 1992 > | edition. > > Back in 1992, job control, outside BSD systems, was still not > all that common (it was in SunOS, Digital Unix (both originally > BSD based) and probablu IRIX, but I think not in AIX or HPUX, etc). I think so in AIX, at least by version 3, and pretty sure yes in HPUX (HPUX implemented the first cut at what became POSIX job control as a hybrid of BSD and SYSV, and Dave Lennert wrote a great paper about it). But you still had to write special-case code to support and use it, since there were definitely system variations. The SYSV.3 variants like SCO and ISC had the especially weird hybrid implementations. I suppose I could look at some of the old bash distributions, especially before autoconf, and see what they had. But without a reference implementation, since it doesn't seem that ksh88 did it that way, why put the note about interactive shells into the 1992 standard at all? Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
The 'trap action sig' form of the command is different from the kernel model, or signal() interface, because all shells have to implement a handler that references the action string and passes it to eval as a special built-in. Whether they use a single function with sigaction(), which has access to the signo field of a siginfo_t, to establish this or multiple entry points to one function body for use with signal() directly is not material. From this it's not unreasonable to expect that 'trap - sig' and 'trap "" sig' may use a different constant to represent SIG_DFLT and SIG_IGN that this eval handler recognizes, without calling signal() or sigaction() each time trap is called. It can just set all handlers at startup to this eval() function then, until a forked utility environment requires the startup state for exec() to match the SIG_IGN state trap doesn't inherit, and modifies the list of action strings directly to represent initial state and changes. This is what I see as the "higher level abstraction" shell's are supposed to implement, anyways. The default for shells is this _trap_eval() function, not SIG_DFLT or SIG_IGN. It can be argued the header is missing SIG_EVAL to reflect this state, to be specific an asynch-signal safe version of system() is the portable means of handling a signal, not simply to kill it or the other default actions. An implementation-defined separate interface to establish the action string associated with each signal would be needed, as invention, to augment signal(); but this is fairly trivial to implement on systems where signal() is a wrapper of sigaction(). In a message dated 4/15/2019 1:08:51 PM Eastern Standard Time, k...@munnari.oz.au writes: Replying to a bunch of messages in one... Date: Mon, 15 Apr 2019 10:26:35 -0400 From: Chet Ramey Message-ID: <7e4691fd-95a8-5cc0-4521-513f1aca7...@case.edu> | I guess Geoff has the last word on the intent. Sure, and that's fine. | It at least tells the user that the SIG_IGN isn't going to change, | regardless of how many trap commands he or she issues. I will comment more on that lower down when I am replying to Geoff's message. | The devil's advocate position here is that there is variation between | implementations, so we shouldn't attempt to standardize anything. When there are good reasons, and users of the variations, that's a good argument. Here we just have an unworkable mess, that no-one understands, and where only the simplest usages are even attempted. This is something that warrants a cleanup. | I don't view blocking signals as changing the state of their disposition. | Blocking is a temporary condition; Not necessarily. If signals are blocked when the shell starts, and the shell doesn't arbitrarily unblock them, then they will remain blocked forever - there's no mechanism (at least no standard mechanism) for a shell user to manipulate the blocking state. chet.ra...@case.edu ikn a different message said: | It's not. It's about why there is a distinction between non-interactive and | interactive shells. Yes, that's what I initially thought, that or something more along those lines - but then everyone else seemed to go the other way. | My guess is that Korn wanted scripts to be able to change traps for signals | ignored at startup, too, but decided that it wasn't backwards-compatible | enough, and ended up just allowing interactive shells to do it. Early versions of that shell had to work in systems with no job control, and so no process groups. In such an environment the script cannot be allowed to alter an ignored signal - or not without some method to find out the current state, and while ksh has trap -p (for named conditions anyway) that's not really a convenient way, though ksh's format for trap -p does make that much easier than everyone else's. But the "ended up" is what the Bourne shell had always done, so unless there's some other reason for believing there was an intended change, I'm not sure I believe that hypothesis. And: chet.ra...@case.edu said in yet another message: | OK, then there must be some other reason that text appears in the 1992 | edition. Back in 1992, job control, outside BSD systems, was still not all that common (it was in SunOS, Digital Unix (both originally BSD based) and probablu IRIX, but I think not in AIX or HPUX, etc). Without job control, and without a reasonable way to test the existing state of a signal, it was crucial that signals ignored on entry to a non-interactive shell continue to be ignored. For interactive shells it makes no difference, as an interactive shell (more or less by definition) cannot be run in the background, whereas a non-interactive one can. Since a shell cannot tell (in a non job control envoronment) whether it is in foreground or background, the best that can be done is whether it is interactive or not, and whether it has signals ignored or not (those it can
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
Replying to a bunch of messages in one... Date:Mon, 15 Apr 2019 10:26:35 -0400 From:Chet Ramey Message-ID: <7e4691fd-95a8-5cc0-4521-513f1aca7...@case.edu> | I guess Geoff has the last word on the intent. Sure, and that's fine. | It at least tells the user that the SIG_IGN isn't going to change, | regardless of how many trap commands he or she issues. I will comment more on that lower down when I am replying to Geoff's message. | The devil's advocate position here is that there is variation between | implementations, so we shouldn't attempt to standardize anything. When there are good reasons, and users of the variations, that's a good argument. Here we just have an unworkable mess, that no-one understands, and where only the simplest usages are even attempted. This is something that warrants a cleanup. | I don't view blocking signals as changing the state of their disposition. | Blocking is a temporary condition; Not necessarily. If signals are blocked when the shell starts, and the shell doesn't arbitrarily unblock them, then they will remain blocked forever - there's no mechanism (at least no standard mechanism) for a shell user to manipulate the blocking state. chet.ra...@case.edu ikn a different message said: | It's not. It's about why there is a distinction between non-interactive and | interactive shells. Yes, that's what I initially thought, that or something more along those lines - but then everyone else seemed to go the other way. | My guess is that Korn wanted scripts to be able to change traps for signals | ignored at startup, too, but decided that it wasn't backwards-compatible | enough, and ended up just allowing interactive shells to do it. Early versions of that shell had to work in systems with no job control, and so no process groups. In such an environment the script cannot be allowed to alter an ignored signal - or not without some method to find out the current state, and while ksh has trap -p (for named conditions anyway) that's not really a convenient way, though ksh's format for trap -p does make that much easier than everyone else's. But the "ended up" is what the Bourne shell had always done, so unless there's some other reason for believing there was an intended change, I'm not sure I believe that hypothesis. And: chet.ra...@case.edu said in yet another message: | OK, then there must be some other reason that text appears in the 1992 | edition. Back in 1992, job control, outside BSD systems, was still not all that common (it was in SunOS, Digital Unix (both originally BSD based) and probablu IRIX, but I think not in AIX or HPUX, etc). Without job control, and without a reasonable way to test the existing state of a signal, it was crucial that signals ignored on entry to a non-interactive shell continue to be ignored. For interactive shells it makes no difference, as an interactive shell (more or less by definition) cannot be run in the background, whereas a non-interactive one can. Since a shell cannot tell (in a non job control envoronment) whether it is in foreground or background, the best that can be done is whether it is interactive or not, and whether it has signals ignored or not (those it can tell.) g...@opengroup.org quoted me, and said: | > Huh? What "trap - $sig" ? | The one three lines above that in my email. (Which is now below, because of | your reordering.) Yes, that I assumed. The point was more what that has to do with anything. The question is what "trap" should output. That cannot depend upon what other commands might perhaps be, or have been issued earlier (except commands that have changed the state). | The output should be a command that sets signals X Y and Z to be ignored. I see from later in your reply that you believe that has always what has been required, and if that were true, there would be less of an issue. But I disagree. | 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. No, that's fine - though there has to be a limit on how much useless imaginary behaviour we explicitly specify the results of ... where possible it is better to simply have a general principle stated, and not try to call out (any) particular cases, except for exceptions. | 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. I have never believed that to be true - but that may be because I've never been a ksh user, and haven't ever attempted to follow all the random stray changes it introduced. However, I can believe that of ksh, as much of the aim of that (all the way down to its model for local variables, declarations, ...) seems to have been inspired by at attempt to make the
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
On 4/15/19 11:07 AM, Joerg Schilling wrote: > Chet Ramey wrote: > >> It's not. It's about why there is a distinction between non-interactive and >> interactive shells. My guess is that Korn wanted scripts to be able to >> change traps for signals ignored at startup, too, but decided that it >> wasn't backwards-compatible enough, and ended up just allowing interactive >> shells to do it. > > I am not sure whether I miss something here, but I cannot see any difference > related to signals that are ignored at shell startup time. > > While ksh93 may accept a command for those signals, the signal itself stays > in > ignored state. OK, then there must be some other reason that text appears in the 1992 edition. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
Chet Ramey wrote: > It's not. It's about why there is a distinction between non-interactive and > interactive shells. My guess is that Korn wanted scripts to be able to > change traps for signals ignored at startup, too, but decided that it > wasn't backwards-compatible enough, and ended up just allowing interactive > shells to do it. I am not sure whether I miss something here, but I cannot see any difference related to signals that are ignored at shell startup time. While ksh93 may accept a command for those signals, the signal itself stays in ignored state. See "psig $$" Jörg -- EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
On 4/15/19 10:33 AM, Robert Elz wrote: > Date:Mon, 15 Apr 2019 09:38:26 -0400 > From:Chet Ramey > Message-ID: > > | On 4/15/19 5:32 AM, Geoff Clare wrote: > | > | > The part in parentheses in the bug 1212 resolution is a reference back > | > to this statement in the standard (line 77504): > | > > | > 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. > | > > | > I expect your guess is right that this behaviour originated with ksh88, > | > but it's origins aren't a factor in the bug 1212 resolution. > | > | It's a factor in why the standard makes the distinction in the first > place. > > I wasn't really sure what the "this" in your original mail referred to, > I thought it might have had something to do with the trap command reporting > signals ignored at entry... > > But if this was really about why signals ignored at entry cannot be > reset by trap commands (in non-interactive shells), then Joerg is correct, > that's original Bourne shell behavoiur and was necessary in the pre job > control world, at least for the terminal generated signals (which are > the only ones normally sometimes ignored on entry to any process). It's not. It's about why there is a distinction between non-interactive and interactive shells. My guess is that Korn wanted scripts to be able to change traps for signals ignored at startup, too, but decided that it wasn't backwards-compatible enough, and ended up just allowing interactive shells to do it. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
Date:Mon, 15 Apr 2019 09:38:26 -0400 From:Chet Ramey Message-ID: | On 4/15/19 5:32 AM, Geoff Clare wrote: | | > The part in parentheses in the bug 1212 resolution is a reference back | > to this statement in the standard (line 77504): | > | > 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. | > | > I expect your guess is right that this behaviour originated with ksh88, | > but it's origins aren't a factor in the bug 1212 resolution. | | It's a factor in why the standard makes the distinction in the first place. I wasn't really sure what the "this" in your original mail referred to, I thought it might have had something to do with the trap command reporting signals ignored at entry... But if this was really about why signals ignored at entry cannot be reset by trap commands (in non-interactive shells), then Joerg is correct, that's original Bourne shell behavoiur and was necessary in the pre job control world, at least for the terminal generated signals (which are the only ones normally sometimes ignored on entry to any process). Setting them to ignored prevented someone from typing an interrupt (or quit) character on the terminal from interrupting a background processes. If a shell script simply doing trap 'echo Finishing; exit' INT (so that it could escape some long running loop if interrupted) would cause that script if run in the backgroud to exit when the user sent an interrupt from the terminal to interrupt some other foreground proceess, then the world would be hopeless (especially considering that there was no way a script could easily work out if it was being run in foreground or background - and the "trap" (no args) command would not list signals being ignored (unless because of a trap '' sig command). The early versions of the standard pre-dated job control being mandated, so had to work in a non-job-control environment. Hence this trap behaviour was a necessity (unless they had invented something new). Now with job control everywhere in interactive shells (which start the non-interactive shells, when there is any terminal type device involved) and process groups to which terminal signals are sent, none of this is really needed any more. kre
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
Robert Elz 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
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
On 4/14/19 8:30 PM, Robert Elz wrote: > That distinction makes no sense to me, That, along with this being only > currently implemented by bash, is what suggests to me that this was probably > not the intended interpretation. I guess Geoff has the last word on the intent. > > | I'd add a little more nuance: it's intended to reveal the state of the > | world that the user can modify (or not, as the case may be). > > That's certainly a possibility. It isn't what I would have considered > likely however. It at least tells the user that the SIG_IGN isn't going to change, regardless of how many trap commands he or she issues. > > | Bash does it lazily, and doesn't pay any extra startup cost for non- > | interactive shells. > > Which will gtenerally help, but then moves the cost to when a "trap" (bare) > command is executed. It's an acceptable compromise that results in a performance benefit in the common cases. > > | Interactive shells add signal handlers for some fatal > | signals to clean up the terminal, > > I don't bother with that. For an interactive shell, there are two > possibilities - either it is a login shell (in the actual sense, rather > than the "argv[0][0] == '-'" sense which causes the shell to act slightly > differently) in which case no-one cares what the state of the terminal > is when the shell exits - it will all be cleaned up before it gets used > again for a new login - or it is not (a login shell), in which case it > almost always has some other interactive process as its parent. That > process needs to be able (one way or another) cope with process aborting > after having altered the terminal state - that the shell mighht be one of > those is unimportant. That's certainly an approach. > > Of course, the NetBSD shell essentially never encounters any of those > signals (unless someone sends one using kill - where they could use SIGKILL > and leave the shell no option). That is, unlike bash, we limit what the > script can do to avoid the kinds of things that bash allows to happen, wich > can lead to SEGV (etc). Eg: we have an arbitrary limit on function nesting > depth, we don't simply allow whatever the implementation can handle before > the stack is exhausted, so these kinds of signals in practice are not a > problem for us. (nb: I am not claiming one method is better than the other, > they both have advvantages.) Bash lets the user tune some of that behavior ($FUNCNEST), and lets others be determined at build time (SOURCENEST_MAX, EVALNEST_MAX), but in general doesn't attempt to place arbitrary limits on it. > > | save the history, > > we don't (currently) ever do that, so that's also not an issue. People are very vocal about that, especially when closing a terminal window with the close button (which sends SIGHUP). Saved history is very important. > > | and run the exit trap. > > and that one I wouldn't even contemplate if the shell has encountered > a fault - if that's happened, something is broken, I would npt like to > contemplate what imaginative "code" it might find to run as an exit trap... > (and can't be done with SIGKILL, so it is not always possible anyway). People are quite vocal about that as well, though it's more of an issue with something like SIGHUP and less with, say, SIGSEGV. > > | There's a little more variation than you might think. > > Thatks - I had not tested that one before. Yet another argument for > cleaning things up here, there is no good reason for these differences. > I don't mean for how they happened historically, but for keeping them now. > We should simply decide what is best and require that. The devil's advocate position here is that there is variation between implementations, so we shouldn't attempt to standardize anything. > > | Because there's no point: these are supposed to be invisible to the user. > > Yes, that makes sense, but one could argue a signal ignored at startup is > also invisible to the user - the very reason that those signals cannot > be trapped, is that we want to pretend that they were never queued for the > process ... that is, there should be no difference after setting a trap > between the case when the signal is simply never sent, and the case when > the signal would have been sent, but is ignored (they have the same effect). > So, one could argue that a script should not be able to tell the difference > between those two cases. It's easier to explain the behavior if you display it as ignored -- at least it's clear what the shell will do with it. > > | I don't have any strong opinion one way or the other -- on this issue, > | at least. Just what I think the standard says now. > > Sure. The problem right now is that the standard doesn't really say > anything about any of this, just: I'm including the text of 1212 in my statement, since that's the current implementation specification (for lack of a better term), though it hasn't made it into a
[1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1212 == Reported By:kre Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1212 Category: Shell and Utilities Type: Enhancement Request Severity: Objection Priority: normal Status: Resolved Name: Robert Elz Organization: User Reference: Section:XCU 2.14 -- trap special builtin Page Number:2420 - 2423 Line Number:77484-5 (and more) Interp Status: --- Final Accepted Text:http://austingroupbugs.net/view.php?id=1212#c4358 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2018-09-28 02:56 UTC Last Modified: 2019-04-15 14:23 UTC == Summary:Enhance trap command == Relationships ID Summary -- related to 0001211 trap (with no args) specifi... == -- (0004361) chet_ramey (reporter) - 2019-04-15 14:23 http://austingroupbugs.net/view.php?id=1212#c4361 -- Re: 4359 Doesn't `trap -p INT' fall under the first sentence of the -p description? "Write to standard output a list of commands associated with each condition operand" Issue History Date ModifiedUsername FieldChange == 2018-09-28 02:56 kreNew Issue 2018-09-28 02:56 kreName => Robert Elz 2018-09-28 02:56 kreSection => XCU 2.14 -- trap special builtin 2018-09-28 02:56 krePage Number => 2420 - 2423 2018-09-28 02:56 kreLine Number => 77484-5 (and more) 2019-04-04 17:35 shware_systems Note Added: 0004356 2019-04-06 07:54 kreNote Added: 0004357 2019-04-09 11:07 geoffclare Note Added: 0004358 2019-04-09 11:09 geoffclare Note Edited: 0004358 2019-04-09 11:11 geoffclare Note Edited: 0004358 2019-04-09 11:13 geoffclare Note Edited: 0004358 2019-04-09 11:19 geoffclare Relationship added related to 0001211 2019-04-09 13:32 joerg Note Added: 0004359 2019-04-09 13:35 joerg Note Edited: 0004359 2019-04-09 13:52 geoffclare Note Edited: 0004358 2019-04-09 14:27 nick Note Added: 0004360 2019-04-10 08:33 geoffclare Note Edited: 0004358 2019-04-11 15:33 geoffclare Note Edited: 0004358 2019-04-11 15:48 geoffclare Interp Status => --- 2019-04-11 15:48 geoffclare Final Accepted Text => http://austingroupbugs.net/view.php?id=1212#c4358 2019-04-11 15:48 geoffclare Status New => Resolved 2019-04-11 15:48 geoffclare Resolution Open => Accepted As Marked 2019-04-11 15:48 geoffclare Tag Attached: issue8 2019-04-15 14:23 chet_ramey Note Added: 0004361 ==
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
Date:Mon, 15 Apr 2019 15:05:50 +0200 From:Joerg Schilling Message-ID: <5cb481ae.vxg6yxdgkfin1rkv%joerg.schill...@fokus.fraunhofer.de> | Wow, this is a long text and I would need more time. Yes, it was... | Let me give some comments: I'd prefer comments on the issues that matter to posix. Various bugs one place or another are just things to get fixed ... bugs that are discovered in off the wall type testing for esoteric issues like this aren't even urgent ones. | Thank you for the hint. I would need to investigate in the reason for that | behavior and fix it. It will be a process group (for the terminal) alteration that's getting missed or performed incorrectly. Or at least that is what it looks like (from the outside.) | "SIGFAIL" is what the shell uses to exit when it is killed itself | by a signal. Oh. What we do when we catch a signal, and then exit, is reset the signal to SIG_DFL (and disable core dumps, but that's not important) and then send the signal to ourselves (again). Then our parent gets a "killed by signal X" status, instead of "exited". | But if you did have a POSIX compliant OS, you should be able to detect that | exit code > 127 if you use waitid(). Yes, I could, but as long as posix keeps saying the the shell exit code is 0..255 (that is, $?) there doesn't seem to be much point. | This is indeed something that has been left over from 1977 when SIGSEGV was | used to extend the heap of the shell. Personally, I think that's fine (not extending the heap that way, but catching any signal a shell desired) - this is another example of a shell resetting an ignored signal to default (or internally trapped, which means the same to a script) because it needs the signal for internal uses.And then "ignored at startup" is interpreted where "startup" means "after initialisation". kre
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
Robert Elz wrote: > I have a small problem with the proposed new wording, that I didn't Wow, this is a long text and I would need more time. Let me give some comments: > [Aside: bosh cannot be used to run this test, when it starts a process > from inside a subshell, and the process does any terminal related > manipulations - like modern interactive shells do to enable command like > editing, the newly created process (shell, or something like "more" or "vi") > is stopped with a SIGTTIN (sometimes SIGTTOU, depending upon what the > process is doing) - and any attempt to continue it simply repeats the > sequence ... bosh obviously has terminal process group issues for processes > started inside a subshell. Note the leading trap command used here is > irrelevant to this problem, inside an interactive bosh simply doing > (bosh) > will cause the newly created bosh to immediately suspend.] This seems to be a problem introduced with adding support for vfork() that resulted in a major performance win. If you chdir sh smake clean smake COPTX=-DNO_VFORK you get a bosh that does not have this problem. Thank you for the hint. I would need to investigate in the reason for that behavior and fix it. > I ran the non-interactive test again using SEGV, with the same result. > bash reports SEGV as ignored, everything else reports nothing. > > For fun, I also ran: > > (trap '' SEGV; $SHELL -c 'kill -s SEGV $$; echo survived') > > everything except bosh reported "survived" - not sure what bosh did there, > it did not seem to dump core however, that subshell exited with status > 208 - which should be the exit status of the shell that sent itself the > SEGV ... 208 is kind of meaningless as a status however, it is > 128, > but is not 128+SEGV. It was irrelevant for this whether it was bosh > running the test, or a different shell. Oh! If I do in an interactive > bosh: > kill -s SEGV $$ > echo $? > the status of the kill ($?) is reported as 2000. (Note this actually needs > to be 2 lines, not one command line with a ';' separator, in that case the > echo never happens, which indicates that bosh is actually catching and > ignoring > the SEGV internally - treating SEGV like other shells treat INT.) 208 > is 2000 & 0xFF. Joerg, your insistence on exit codes wider than 8 bits > breaks things!) There is also the question of why bosh is catching SEGV Sorry, but this is something that AT seems to have changed for SVr2 (1983) or even earlier. This is "SIGFAIL" that in older versions of the shell has been 3. "SIGFAIL" is what the shell uses to exit when it is killed itself by a signal. But if you did have a POSIX compliant OS, you should be able to detect that exit code > 127 if you use waitid(). Given that the first UNIX clone (UNOS) from 1980, made by former AT people in the company "Charles River Data Systems" already did support 32 bits in exit codes and that even SVr4 from 1989 does it, this is at least 30 years of existing practice. > signals in a non-interactive shell started with SIGSEGV as SIG_IGN (surely > it isn't still doing the ancient "malloc (sbrk()) more memory on SEGV" trick > that used to be used, until it was worked out not to be portable) ? This is indeed something that has been left over from 1977 when SIGSEGV was used to extend the heap of the shell. If you don't have it, the login shell will not survive a SIGSEGV. > That is, in all shells possibly except bosh, the SEGV was really ignored). > > A subsequest test: > > (trap '' SEGV; > $SHELL -c 'trap "echo violated" SEGV; kill -s SEGV $$; echo survived') > > (actually entered as one line, divided this way for the e-mail, though > it should be OK to cut and enter the two line version) had similar > results, all shells except bosh and zsh say just "survived", bosh & zsh > output both violated and survived. See above, this is very old behavior. It should be changed when not compiled with Historical Bourne Shell behavior and when SIGSEGV is not in it's default state. Jörg -- EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
Chet Ramey wrote, on 14 Apr 2019: > > On 4/13/19 5:47 PM, Robert Elz wrote: > > Date:Sat, 13 Apr 2019 13:52:17 -0400 > > From:Chet Ramey > > > > | My reading of the plain language of the standard is that it implies you > > | list signals that were ignored at a non-interactive shell start. > > > > I agree, that's one interpretation, but if that's what is intended, why only > > non-interactive shells? Why not simply list (as ignored) all signals that > > are being ignored (for any shell). > > My guess is that this came in from ksh88, and that Korn wanted to do it for > interactive and non-interactive shells both, but didn't pull the trigger on > non-interactive shells for backwards compatibility. Geoff would know. The part in parentheses in the bug 1212 resolution is a reference back to this statement in the standard (line 77504): 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. I expect your guess is right that this behaviour originated with ksh88, but it's origins aren't a factor in the bug 1212 resolution. 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, even if the script has executed "trap - $sig" to (try to) reset that signal (and the shell didn't report an error). In an interactive shell, the "trap - $sig" should work, and so the signal will not be listed. > > Further, while not impossible, it would be unusual for the standard to > > specify something that only one shell implements, with all others > > (currently) behaving differently. > > Not that unusual, though it happens less frequently now. 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. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
Date:Sun, 14 Apr 2019 14:56:41 -0400 From:Chet Ramey Message-ID: | > If you mean to the user of the result (consumer of the output of | > the trap command) then I mostly agree. It makes a difference to the | > implementation however. | | A small one, yes. What I meant was that we have to implement different things depending upon the interpretation, not that one is necessarily easier than the other. | > | My reading of the plain language of the standard is that it implies you | > | list signals that were ignored at a non-interactive shell start. | > | > I agree, that's one interpretation, but if that's what is intended, | > why only non-interactive shells? Why not simply list (as ignored)\ | > all signals that are being ignored (for any shell). | | My guess is that this came in from ksh88, and that Korn wanted to do it for | interactive and non-interactive shells both, but didn't pull the trigger on | non-interactive shells for backwards compatibility. I think the discussion has wandered a little here. I wasn't asking why interactive and non-interactive shells treat signals ignored at startup differently (I think I understand that, though I am not sure it makes sense any more) but why the (new) language proposed for the (bare) trap command, which (under this interpretation of its meaning) would require signals ignored on entry to a non-interactive shell to be included in the output, but not signals ignored on entry to an interactive shell (in both cases, this means particularly signals for which there has been no attempt at a trap command to alter the state). That distinction makes no sense to me, That, along with this being only currently implemented by bash, is what suggests to me that this was probably not the intended interpretation. | I'd add a little more nuance: it's intended to reveal the state of the | world that the user can modify (or not, as the case may be). That's certainly a possibility. It isn't what I would have considered likely however. | Bash does it lazily, and doesn't pay any extra startup cost for non- | interactive shells. Which will gtenerally help, but then moves the cost to when a "trap" (bare) command is executed. | Interactive shells add signal handlers for some fatal | signals to clean up the terminal, I don't bother with that. For an interactive shell, there are two possibilities - either it is a login shell (in the actual sense, rather than the "argv[0][0] == '-'" sense which causes the shell to act slightly differently) in which case no-one cares what the state of the terminal is when the shell exits - it will all be cleaned up before it gets used again for a new login - or it is not (a login shell), in which case it almost always has some other interactive process as its parent. That process needs to be able (one way or another) cope with process aborting after having altered the terminal state - that the shell mighht be one of those is unimportant. Of course, the NetBSD shell essentially never encounters any of those signals (unless someone sends one using kill - where they could use SIGKILL and leave the shell no option). That is, unlike bash, we limit what the script can do to avoid the kinds of things that bash allows to happen, wich can lead to SEGV (etc). Eg: we have an arbitrary limit on function nesting depth, we don't simply allow whatever the implementation can handle before the stack is exhausted, so these kinds of signals in practice are not a problem for us. (nb: I am not claiming one method is better than the other, they both have advvantages.) | save the history, we don't (currently) ever do that, so that's also not an issue. | and run the exit trap. and that one I wouldn't even contemplate if the shell has encountered a fault - if that's happened, something is broken, I would npt like to contemplate what imaginative "code" it might find to run as an exit trap... (and can't be done with SIGKILL, so it is not always possible anyway). | There's a little more variation than you might think. Thatks - I had not tested that one before. Yet another argument for cleaning things up here, there is no good reason for these differences. I don't mean for how they happened historically, but for keeping them now. We should simply decide what is best and require that. | The variant of the first one that I get more often is "that's dumb, why | does the shell do that?" Yes, today that question makes sense. In ancient times there was an easy answer, but today, there isn't really.Keeping the ancient requirements on the trao command doesn't really make any sense any mroe. | The second-most one is, of course, is "why | didn't my trap command change anything?" Also a good question. Which we should (IMO) resolve by making it do something, rather than by making it easier for the user to see that it in fact did not change anything. |
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
On 4/13/19 5:47 PM, Robert Elz wrote: > Date:Sat, 13 Apr 2019 13:52:17 -0400 > From:Chet Ramey > Message-ID: > > | There's no practical difference, really. > > If you mean to the user of the result (consumer of the output of > the trap command) then I mostly agree. It makes a difference to the > implementation however. A small one, yes. > | My reading of the plain language of the standard is that it implies you > | list signals that were ignored at a non-interactive shell start. > > I agree, that's one interpretation, but if that's what is intended, why only > non-interactive shells? Why not simply list (as ignored) all signals that > are being ignored (for any shell). My guess is that this came in from ksh88, and that Korn wanted to do it for interactive and non-interactive shells both, but didn't pull the trigger on non-interactive shells for backwards compatibility. Geoff would know. > > Further, while not impossible, it would be unusual for the standard to > specify something that only one shell implements, with all others > (currently) behaving differently. Not that unusual, though it happens less frequently now. > > | It's a better implementation, anyway, since it's otherwise difficult > | to find out why your trap command has no effect. > > That depends upon the intent of the (bare) trap command. Is it intended > to keep track of what the shell has changed, or at least attempted to have > changed, or to reveal the state of the world? I'd add a little more nuance: it's intended to reveal the state of the world that the user can modify (or not, as the case may be). > Historically (and probably for most shells, currently), shells did not look > at all of the signals to discover their state - that's mostly irrelevant, > those signals that the shell needs to manipulate in order to operate > correctly, and those that the user alters via the trap command are > examined, everything else is ignored. That's cheaper at startup. Bash does it lazily, and doesn't pay any extra startup cost for non- interactive shells. Interactive shells add signal handlers for some fatal signals to clean up the terminal, save the history, and run the exit trap. > Further, fpr most current shells, the output of trap shows the trap > commands that the shell has executed, not the actual results of those > after the "signals ignored at startup for non-interactive shells" rule > is applied, that is if my script does > trap 'echo foo' INT > the trap command outputs > trap - 'echo foo' INT > (or SIGINT) regardless of whether or not SIGINT was ignored when the > shell started. There's a little more variation than you might think. Given that command, ash-derived shells and mksh output the above, bash and ksh93 output the original `trap - '' INT', and the Bourne shell and yash don't output anything. > And while some users might wonder why a SIGINT doesn't cause "foo" to > be output, the explanation "SIGINT must have been ignored when the > shell started" is not that difficult to make, or to understand. The > harder one for users to grasp is "why didn't the shell object to the > trap command in that case?" The variant of the first one that I get more often is "that's dumb, why does the shell do that?" The second-most one is, of course, is "why didn't my trap command change anything?" > | This came along with an interpretation by this group concerning how to > | display traps in subshells. I don't have access to my mail archives right > | now, so I can't reference any discussion. > > The result of that is in the current (TC2) text already, and certainly there > there's no mention of this particular aspect. I'm not convinced. I responded to the bug-bash thread that prompted this with a promise to start a discussion on austingroup-bugs, and since I didn't open an interpretation request there's no reason to expect any of it to have shown up in the standard. I'll look at my archives. > Incidenrtally, if the shell is going to reveal the state of the > kernel/shell signal setting, what doies it report about any signals > that the shell has trapped for its own use (so it can work correctly) > but which the user has not trapped (or ignored)? Because there's no point: these are supposed to be invisible to the user. If the shell catches SIGUSR1 internally, the user is still allowed to set a trap for it and expect that the trap command will be executed, regardless of whatever the shell does internally, and set it to SIG_IGN or SIG_DFL and expect that will be honored as well. Bash catches a bunch of fatal signals when the shell is interactive, and still allows traps on them. SIGCHLD is really the only special one; bash doesn't allow it to be ignored. I suppose it could -- if you want to shoot yourself in the foot, the shell will hand you a loaded gun -- but I've never done that. > And then we really also need to decide if we really need to keep the >
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
Date:Sat, 13 Apr 2019 13:52:17 -0400 From:Chet Ramey Message-ID: | There's no practical difference, really. If you mean to the user of the result (consumer of the output of the trap command) then I mostly agree. It makes a difference to the implementation however. | My reading of the plain language of the standard is that it implies you | list signals that were ignored at a non-interactive shell start. I agree, that's one interpretation, but if that's what is intended, why only non-interactive shells? Why not simply list (as ignored) all signals that are being ignored (for any shell). Further, while not impossible, it would be unusual for the standard to specify something that only one shell implements, with all others (currently) behaving differently. | It's a better implementation, anyway, since it's otherwise difficult | to find out why your trap command has no effect. That depends upon the intent of the (bare) trap command. Is it intended to keep track of what the shell has changed, or at least attempted to have changed, or to reveal the state of the world? Historically (and probably for most shells, currently), shells did not look at all of the signals to discover their state - that's mostly irrelevant, those signals that the shell needs to manipulate in order to operate correctly, and those that the user alters via the trap command are examined, everything else is ignored. That's cheaper at startup. Further, fpr most current shells, the output of trap shows the trap commands that the shell has executed, not the actual results of those after the "signals ignored at startup for non-interactive shells" rule is applied, that is if my script does trap 'echo foo' INT the trap command outputs trap - 'echo foo' INT (or SIGINT) regardless of whether or not SIGINT was ignored when the shell started. And while some users might wonder why a SIGINT doesn't cause "foo" to be output, the explanation "SIGINT must have been ignored when the shell started" is not that difficult to make, or to understand. The harder one for users to grasp is "why didn't the shell object to the trap command in that case?"And that's something where all shells behave the same (other than where the signal is KILL or STOP - which is an entirely different issue.) | This came along with an interpretation by this group concerning how to | display traps in subshells. I don't have access to my mail archives right | now, so I can't reference any discussion. The result of that is in the current (TC2) text already, and certainly there there's no mention of this particular aspect. As I said in the previous message, I don't particularly care which interpretation is selected - just that the wording be improved to make it clear what it is intended to mean. This also could be something (additional) where trap and trap -p could differ, with one of them reporting actual state of the world as seen by the kernel (along with the actual internal shell action string for caught signals) and the other showing the actions of the shell (effective or not as far as the kernel interactions are concerned). Incidenrtally, if the shell is going to reveal the state of the kernel/shell signal setting, what doies it report about any signals that the shell has trapped for its own use (so it can work correctly) but which the user has not trapped (or ignored)? If we're reporting the actual kernel signal setting state, the output would need to be something like trap -- '*internel*' CHLD though most likely not exactly that, and finding something would be difficult, as any string except '-' and '' could be the user's trap command, perhaps trap -- '()' CHLD as at least that's an invalid action (cannot succeed if executed) so isn't something likeley for the application to set, pr perhaps trap -- '#internal' CHLD ?? Or, of course, a new option could be added to distinguish these two output forms (reporting previous trap commands, or reportng the state of the world), with the mew option (for consistency with the way most shells work now) output the state of the signals, as understood by the kernel (could even have an annotation to note blocked signals, for which we probably should have a method to accomplish at sh level anyway, but we don't .., and this is not the place to invent one) and without the option do the traditional thing, and list the settings made by earlier trap commands, whether or not they were effective in altering the kernel's signal disposition (which is why most shells still allow SIGKILL/SIGSTOP to be "trapped" and report that from (bare) trap, even though it is all a hoax). (A new option like this could apply both with, and without -p, and even in trap setting mode, could be used to cause the trap command to error, if the shell cannot do what the user has asked, rather that as currently, simply silently ignoring that.) And then we really also
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
On 4/12/19 10:51 PM, Robert Elz wrote: > The wording I have a problem with is: > > On page 2420 line 77514 after applying bug 1211 change: > [...] > to: > [...] 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 problematic part is that in parentheses, as I cannot work out what > that means. > > It could mean: > > "also list in the output signals that were ignored upon >entry to a non-interactive shell" > > (though what that would imply for interactive shells is anyone's guess) > > or it could mean > > "include in the list any conditions not in the default state, >even if the associated signal was ignored upon entry to a >non-interactive shell, and consequently the trap will never >actually fire" There's no practical difference, really. My reading of the plain language of the standard is that it implies you list signals that were ignored at a non-interactive shell start. It's a better implementation, anyway, since it's otherwise difficult to find out why your trap command has no effect. > On one hand, if one regards the purpose to the (bare) trap command as > reporting what has happened elsewhere in the shell, then the majority > do exactly that. If one regards the purpose of the command as reporting > the state of signals in the shell (what will be passed down to child > processes) then what bash does is more accurate (in general). I added displaying the disposition of signals ignored at shell start in 2010 (which first showed up in bash-4.2) as the result of a feature request for exactly that -- to show the true disposition of signals in subshells. This came along with an interpretation by this group concerning how to display traps in subshells. I don't have access to my mail archives right now, so I can't reference any discussion. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
I have a small problem with the proposed new wording, that I didn't
notice before -- nothing to do with the new trap -p part, but in the
revisions to the old wording about the older forms of the trap
command that accompany it.
That has led me to something of a wilder voyage of discovery with traps
and shells...
The wording I have a problem with is:
On page 2420 line 77514 after applying bug 1211 change:
[...]
to:
[...] 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 problematic part is that in parentheses, as I cannot work out what
that means.
It could mean:
"also list in the output signals that were ignored upon
entry to a non-interactive shell"
(though what that would imply for interactive shells is anyone's guess)
or it could mean
"include in the list any conditions not in the default state,
even if the associated signal was ignored upon entry to a
non-interactive shell, and consequently the trap will never
actually fire"
(for interactive shells the assumption here is that trap commands
work as directed, even if the signal was ignored on entry, so nothing
special needs be said about that)
or I supposed it might have been intended to mean something else,
perhaps even both of those.Whichvever, it needs clarification.
I did a survey of what shells actually do here (non-nteractive shells),
and bash is the only one I could find that is anything like the first,
everything else reports signals that have been altered in the shell,
that is, the results of previously executed trap commands, and only
that (though some omit any attempt that was made to set/ignore KILL
or STOP, and don't include those in the output).
("everything else" includes ksh93, mksh, old pdksh, dash, yash,
zsh (in --emulate sh mode), bosh, and the NetBSD and FreeBSD shells)
The test was
(trap '' INT; $SHELL -c trap)
bash reports:
trap -- '' SIGINT
all the others simply exit, with no output.
It turns out that there is actually no difference between interactive
and non-interactive shells in this regard, all of them do the same
thing when in interactive mode
(trap '' INT; $SHELL)
trap
exit
In this scenario (note the "trap" and "exit" commands are interactive
commands given to the interactive shell that starts) the results are
the same as above (except we get PS1 output of course, and whatever the
shell in question says when an interactive shell exits).
[Aside: bosh cannot be used to run this test, when it starts a process
from inside a subshell, and the process does any terminal related
manipulations - like modern interactive shells do to enable command like
editing, the newly created process (shell, or something like "more" or "vi")
is stopped with a SIGTTIN (sometimes SIGTTOU, depending upon what the
process is doing) - and any attempt to continue it simply repeats the
sequence ... bosh obviously has terminal process group issues for processes
started inside a subshell. Note the leading trap command used here is
irrelevant to this problem, inside an interactive bosh simply doing
(bosh)
will cause the newly created bosh to immediately suspend.]
(Other than that bosh bug, which is obviously just a bug, and unrelated,
bosh works the same as everyone else, sans bash, if started from some
other shell this way.)
I have no real opinion on which is better, regardless of the shell I
maintain being one of the majority.
On one hand, if one regards the purpose to the (bare) trap command as
reporting what has happened elsewhere in the shell, then the majority
do exactly that. If one regards the purpose of the command as reporting
the state of signals in the shell (what will be passed down to child
processes) then what bash does is more accurate (in general).
For this, we really need to consider differently (because of history) the
signals that the shell traps for its own purposes (at least when interactive)
and those which it should only ever touch if the user/script says so.
The first set includes INT HUP QUIT TTIN TTOU TSTP, the second set
(usually) things like SIGV EMT BUS USR1 ... (then there are a couple
which different shells might handle differently, like ALRM). And of
course KILL and STOP are different again. Note that I have not attempted
to catageroise all signals into these groups - that's not important.
I ran the non-interactive test again using SEGV, with the same result.
bash reports SEGV as ignored, everything else reports nothing.
For fun, I also ran:
(trap '' SEGV; $SHELL -c 'kill -s SEGV $$; echo survived')
everything except bosh reported "survived" - not sure what bosh did there,
it did not seem to dump core however, that subshell exited with status
208 - which should be the exit status of the shell that sent
[1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
The following issue has been RESOLVED. == http://austingroupbugs.net/view.php?id=1212 == Reported By:kre Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1212 Category: Shell and Utilities Type: Enhancement Request Severity: Objection Priority: normal Status: Resolved Name: Robert Elz Organization: User Reference: Section:XCU 2.14 -- trap special builtin Page Number:2420 - 2423 Line Number:77484-5 (and more) Interp Status: --- Final Accepted Text:http://austingroupbugs.net/view.php?id=1212#c4358 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2018-09-28 02:56 UTC Last Modified: 2019-04-11 15:48 UTC == Summary:Enhance trap command == Relationships ID Summary -- related to 0001211 trap (with no args) specifi... == Issue History Date ModifiedUsername FieldChange == 2018-09-28 02:56 kreNew Issue 2018-09-28 02:56 kreName => Robert Elz 2018-09-28 02:56 kreSection => XCU 2.14 -- trap special builtin 2018-09-28 02:56 krePage Number => 2420 - 2423 2018-09-28 02:56 kreLine Number => 77484-5 (and more) 2019-04-04 17:35 shware_systems Note Added: 0004356 2019-04-06 07:54 kreNote Added: 0004357 2019-04-09 11:07 geoffclare Note Added: 0004358 2019-04-09 11:09 geoffclare Note Edited: 0004358 2019-04-09 11:11 geoffclare Note Edited: 0004358 2019-04-09 11:13 geoffclare Note Edited: 0004358 2019-04-09 11:19 geoffclare Relationship added related to 0001211 2019-04-09 13:32 joerg Note Added: 0004359 2019-04-09 13:35 joerg Note Edited: 0004359 2019-04-09 13:52 geoffclare Note Edited: 0004358 2019-04-09 14:27 nick Note Added: 0004360 2019-04-10 08:33 geoffclare Note Edited: 0004358 2019-04-11 15:33 geoffclare Note Edited: 0004358 2019-04-11 15:48 geoffclare Interp Status => --- 2019-04-11 15:48 geoffclare Final Accepted Text => http://austingroupbugs.net/view.php?id=1212#c4358 2019-04-11 15:48 geoffclare Status New => Resolved 2019-04-11 15:48 geoffclare Resolution Open => Accepted As Marked ==
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
Don Cragun wrote, on 09 Apr 2019: > > > On Apr 9, 2019, at 7:35 AM, Geoff Clare wrote: > > > >> -- > >> (0004360) nick (manager) - 2019-04-09 14:27 > >> http://austingroupbugs.net/view.php?id=1212#c4360 > >> -- > >> ... ... ... > >> > >> I believe it is incorrect to say "shall silently ignore" here. Many shells > >> permit a trap of these signals, even though they cannot be caught or > >> ignored. > > > > But the existing text says that if you try to set a trap for SIGKILL > > or SIGSTOP the behavior is undefined. > > > > So at the point where you execute "trap -p" the output either indicates > > that they are set to default or you are already in the realms of > > undefined behaviour. > > If the shell's man page says what happens in those undefined cases > and a script's documentation says that the environment in which it > runs has to support that extension, the application could still be > a Conforming POSIX Application Using Extensions. And, if the shell > is going to report (for instance) that a trap has been set for the > SIGKILL signal that means that it previously allowed the application > to set a trap for the SIGKILL signal. Requiring that it accept an > attempt to reset it to a value that it previously accepted doesn't > seem to me to be a requirement that any shell should reject. > > If a shell doesn't want to reset a signal that won't be effective, it > shouldn't report the setting of a trap for that signal in the output > it produces for the "trap" or "trap -p" commands. Okay, you've convinced me. I've updated note 4358. The new text is not quite what Nick suggested, as I don't think that went far enough - it required that no diagnostic is produced but would allow a non-zero exit status. (I think it could also still be interpreted as allowing any form of undefined behaviour other than a diagnostic message.) Note 4358 now says: If this set includes conditions corresponding to the SIGKILL and SIGSTOP signals, the shell shall accept them when the output is reinput to the shell (where accepting them means they do not cause a non-zero exit status, a diagnostic message, or undefined behavior). > However, concerning a question that was raised earlier about which > shells are required to process the output produced by the "trap" an > "trap -p" commands... I think that the requirement only applies to > the instance of the shell that produced the output. A non-interactive > shell is not allowed to trap or reset the behavior of a signal that > was ignored when the shell was started. So passing the output of > "trap" from one instance of a shell to another instance of the same > shell cannot require a non-interactive shell to change the state of > a signal that was ignored when it was invoked. Good point. Perhaps instead of: The shell shall format the output, including the proper use of quoting, so that it is suitable for reinput to the shell as commands that achieve the same trapping results for the set of conditions included in the output. note 4358 should say: The shell shall format the output, including the proper use of quoting, so that it is suitable for reinput to the shell as commands that achieve the same trapping results for the set of conditions included in the output, except for signals that were ignored on entry to the shell as described above. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
> On Apr 9, 2019, at 7:35 AM, Geoff Clare wrote: > >> -- >> (0004360) nick (manager) - 2019-04-09 14:27 >> http://austingroupbugs.net/view.php?id=1212#c4360 >> -- >> ... ... ... >> >> I believe it is incorrect to say "shall silently ignore" here. Many shells >> permit a trap of these signals, even though they cannot be caught or >> ignored. > > But the existing text says that if you try to set a trap for SIGKILL > or SIGSTOP the behavior is undefined. > > So at the point where you execute "trap -p" the output either indicates > that they are set to default or you are already in the realms of > undefined behaviour. > > -- > Geoff Clare > The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England Hi Geoff, If the shell's man page says what happens in those undefined cases and a script's documentation says that the environment in which it runs has to support that extension, the application could still be a Conforming POSIX Application Using Extensions. And, if the shell is going to report (for instance) that a trap has been set for the SIGKILL signal that means that it previously allowed the application to set a trap for the SIGKILL signal. Requiring that it accept an attempt to reset it to a value that it previously accepted doesn't seem to me to be a requirement that any shell should reject. If a shell doesn't want to reset a signal that won't be effective, it shouldn't report the setting of a trap for that signal in the output it produces for the "trap" or "trap -p" commands. However, concerning a question that was raised earlier about which shells are required to process the output produced by the "trap" an "trap -p" commands... I think that the requirement only applies to the instance of the shell that produced the output. A non-interactive shell is not allowed to trap or reset the behavior of a signal that was ignored when the shell was started. So passing the output of "trap" from one instance of a shell to another instance of the same shell cannot require a non-interactive shell to change the state of a signal that was ignored when it was invoked. Nonetheless, a parent shell gathering settings from a subshell, such as with traps=$(trap -p) has to be processed correctly by the parent when given the command: eval "$traps" Cheers, Don
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
> -- > (0004360) nick (manager) - 2019-04-09 14:27 > http://austingroupbugs.net/view.php?id=1212#c4360 > -- > In the proposed change on page 2420 line 77522 after applying bug 1211 > change: > > The shell shall format the output, including the proper use of quoting, so > that it is suitable for reinput to the shell as commands that achieve the > same trapping results for the set of conditions included in the output. If > this set includes conditions corresponding to the SIGKILL and SIGSTOP > signals, the shell shall silently ignore them when the output is reinput to > the shell. > > > I believe it is incorrect to say "shall silently ignore" here. Many shells > permit a trap of these signals, even though they cannot be caught or > ignored. But the existing text says that if you try to set a trap for SIGKILL or SIGSTOP the behavior is undefined. So at the point where you execute "trap -p" the output either indicates that they are set to default or you are already in the realms of undefined behaviour. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
[1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1212 == Reported By:kre Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1212 Category: Shell and Utilities Type: Enhancement Request Severity: Objection Priority: normal Status: New Name: Robert Elz Organization: User Reference: Section:XCU 2.14 -- trap special builtin Page Number:2420 - 2423 Line Number:77484-5 (and more) Interp Status: --- Final Accepted Text: == Date Submitted: 2018-09-28 02:56 UTC Last Modified: 2019-04-09 14:27 UTC == Summary:Enhance trap command == Relationships ID Summary -- related to 0001211 trap (with no args) specifi... == -- (0004360) nick (manager) - 2019-04-09 14:27 http://austingroupbugs.net/view.php?id=1212#c4360 -- In the proposed change on page 2420 line 77522 after applying bug 1211 change: The shell shall format the output, including the proper use of quoting, so that it is suitable for reinput to the shell as commands that achieve the same trapping results for the set of conditions included in the output. If this set includes conditions corresponding to the SIGKILL and SIGSTOP signals, the shell shall silently ignore them when the output is reinput to the shell. I believe it is incorrect to say "shall silently ignore" here. Many shells permit a trap of these signals, even though they cannot be caught or ignored. When you request a list of currently set traps, that (meaningless) action is listed. So the shell does not ignore the setting ... it is doing something with it. It is ignoring the error that occurs should it call signal() or sigaction() on these signals. The important thing is that the list produced by trap -p can be re-input without an error being reported, so you don't need to filter out those uncatchable signals from the list. So I believe it would be better to replace "the shell shall silently ignore them" with "the shell shall not produce any diagnostic message with respect to these signals", leaving it unspecified as to what else it might or might not do. Issue History Date ModifiedUsername FieldChange == 2018-09-28 02:56 kreNew Issue 2018-09-28 02:56 kreName => Robert Elz 2018-09-28 02:56 kreSection => XCU 2.14 -- trap special builtin 2018-09-28 02:56 krePage Number => 2420 - 2423 2018-09-28 02:56 kreLine Number => 77484-5 (and more) 2019-04-04 17:35 shware_systems Note Added: 0004356 2019-04-06 07:54 kreNote Added: 0004357 2019-04-09 11:07 geoffclare Note Added: 0004358 2019-04-09 11:09 geoffclare Note Edited: 0004358 2019-04-09 11:11 geoffclare Note Edited: 0004358 2019-04-09 11:13 geoffclare Note Edited: 0004358 2019-04-09 11:19 geoffclare Relationship added related to 0001211 2019-04-09 13:32 joerg Note Added: 0004359 2019-04-09 13:35 joerg Note Edited: 0004359 2019-04-09 13:52 geoffclare Note Edited: 0004358 2019-04-09 14:27 nick Note Added: 0004360 ==
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
Robert Elz wrote, on 09 Apr 2019:
>
> Just one minor note, which applies to both issue 1211 and 1212
> resolutions... (or resolution and proposed resolution I guess)
>
> Both of the workaround methods (added in 1211, and discussed more/altered
> in 1212) have race conditions, not only the 2nd (longer) one - that one has
> a bigger window for something to fall into, but they both reset the
> traps to default, and then set them back to the way they were.
Good point. I have updated note 4358 in bug 1212 to account for this.
I'm not sure it's worth reopening 1211 to fix it there, since it's
extremely unlikely now that we'll do a TC3, so 1211 and 1212 will
end up being applied in the same revision.
> In the application usage section (of 1212) it might be worth adding
> an additional option .. when only one (or a small number) of trap(s)
> is(are) being modified, the following will work...
>
> prev_int_trap=$(trap -p INT); trap 'new trap command' INT
> # do whatever
> eval "${prev_int_trap}"
>
> rather than futzing with all of the traps.
There is already an example in my proposed changes that uses that method.
It's after the "or:" in the page 2420 line 77524 change.
> One additional question that is worth considering wrt this, and other
> similar commands (set +o, export -p, ...) is whether when the standard
> says:
> "so that it is suitable for reinput to the shell"
> is that intended to be read "for reinput to the same instance of
> the shell as saved it" or "for reinput to that shell, or any other
> instantiation of the same process", or "for reinput to any posix
> conformant shell" ?
I believe "the shell" is intended to mean the sh utility (as found by
the PATH value in a conforming environment) on a particular
implementation. So it should be possible to take the output and reinput
it to any invocation of the same shell on the same implementation.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
> -- > (0004359) joerg (reporter) - 2019-04-09 13:32 > http://austingroupbugs.net/view.php?id=1212#c4359 > -- > Hi Geoff, your text does not include an explanation on what should > happen with e.g. > >trap -p INT > That's covered by the description of the -p option (the page 2421 line 77538 change in note 4358). -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
[1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1212 == Reported By:kre Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1212 Category: Shell and Utilities Type: Enhancement Request Severity: Objection Priority: normal Status: New Name: Robert Elz Organization: User Reference: Section:XCU 2.14 -- trap special builtin Page Number:2420 - 2423 Line Number:77484-5 (and more) Interp Status: --- Final Accepted Text: == Date Submitted: 2018-09-28 02:56 UTC Last Modified: 2019-04-09 13:32 UTC == Summary:Enhance trap command == Relationships ID Summary -- related to 0001211 trap (with no args) specifi... == -- (0004359) joerg (reporter) - 2019-04-09 13:32 http://austingroupbugs.net/view.php?id=1212#c4359 -- Hi Geoff, your text does not include an explanation on what should happen with e.g. trap -p INT The easy way to implement -p results in -p being ignored in such a case and the SIGINT trap restored to it's default. If you like to require that "trap -p INT" lists the trap state for SIGINT, I would need to restructure the trap implementation in the Bourne Shell. Issue History Date ModifiedUsername FieldChange == 2018-09-28 02:56 kreNew Issue 2018-09-28 02:56 kreName => Robert Elz 2018-09-28 02:56 kreSection => XCU 2.14 -- trap special builtin 2018-09-28 02:56 krePage Number => 2420 - 2423 2018-09-28 02:56 kreLine Number => 77484-5 (and more) 2019-04-04 17:35 shware_systems Note Added: 0004356 2019-04-06 07:54 kreNote Added: 0004357 2019-04-09 11:07 geoffclare Note Added: 0004358 2019-04-09 11:09 geoffclare Note Edited: 0004358 2019-04-09 11:11 geoffclare Note Edited: 0004358 2019-04-09 11:13 geoffclare Note Edited: 0004358 2019-04-09 11:19 geoffclare Relationship added related to 0001211 2019-04-09 13:32 joerg Note Added: 0004359 ==
Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
That looks fine to me.
Just one minor note, which applies to both issue 1211 and 1212
resolutions... (or resolution and proposed resolution I guess)
Both of the workaround methods (added in 1211, and discussed more/altered
in 1212) have race conditions, not only the 2nd (longer) one - that one has
a bigger window for something to fall into, but they both reset the
traps to default, and then set them back to the way they were.
That is, if in the first example, SIGINT was trapped/ignored previously,
and so saved in save_traps when that example does save_traps=$(trap)
then when we later do eval "$save_traps" which expands to
trap - INT QUIT; trap 'whatever' INT; ...
and there's still that gap when SIGINT is set to SIG_DFL, before it
is trapped again.
With the current text, and what is possible in tc3, I do not believe
there is any simple way around that - one could attempt to parse the
output of $(trap) and see if there is a command to set SIGINT, but
that's not at all easy -- one cannot simply look for an occurrence of
INT in the output for example. The most likely way to work is
probably to redefine the trap command temporarily (alias, or function,
whatever works) and eval "$saved_traps" and then in the not-really-trap
command that gets executed, look and see if any of the commands affects
SIGINT, and if so, remember that for later - that is, just don't include
it in the "trap - INT QUIT" part that is prepended. (This is a Martijn
Dekker technique, for correct attribution.) But that really is ugly.
Beyond that:
In the application usage section (of 1212) it might be worth adding
an additional option .. when only one (or a small number) of trap(s)
is(are) being modified, the following will work...
prev_int_trap=$(trap -p INT); trap 'new trap command' INT
# do whatever
eval "${prev_int_trap}"
rather than futzing with all of the traps.Which method to use
(save all, or just the one(s) being modified) will depend upon the
needs of the script of course.
One additional question that is worth considering wrt this, and other
similar commands (set +o, export -p, ...) is whether when the standard
says:
"so that it is suitable for reinput to the shell"
is that intended to be read "for reinput to the same instance of
the shell as saved it" or "for reinput to that shell, or any other
instantiation of the same process", or "for reinput to any posix
conformant shell" ?
Eg: a shell that (already) supports $'..' quoting might decide to
use that to quote the output, but that would not then work as input
to some other shell which does not (yet) support that (given that it
is not yet in the standard) or even to an older version of the shell
which generated it. What is actually expected to work here?
Can I save the traps/exports/options in bash and input them into dash
or mksh and expect that to work?Or is this really just "the exact
same shell instance" only, (that is, save and restore, around a temporary
alteration in options/traps/... within one shell) or perhaps to the same
shell (as in executing binary file) if not the same instance of it ?
kre
[1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
The following issue has been set as RELATED TO issue 0001211. == http://austingroupbugs.net/view.php?id=1212 == Reported By:kre Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1212 Category: Shell and Utilities Type: Enhancement Request Severity: Objection Priority: normal Status: New Name: Robert Elz Organization: User Reference: Section:XCU 2.14 -- trap special builtin Page Number:2420 - 2423 Line Number:77484-5 (and more) Interp Status: --- Final Accepted Text: == Date Submitted: 2018-09-28 02:56 UTC Last Modified: 2019-04-09 11:19 UTC == Summary:Enhance trap command == Relationships ID Summary -- related to 0001211 trap (with no args) specifi... == Issue History Date ModifiedUsername FieldChange == 2018-09-28 02:56 kreNew Issue 2018-09-28 02:56 kreName => Robert Elz 2018-09-28 02:56 kreSection => XCU 2.14 -- trap special builtin 2018-09-28 02:56 krePage Number => 2420 - 2423 2018-09-28 02:56 kreLine Number => 77484-5 (and more) 2019-04-04 17:35 shware_systems Note Added: 0004356 2019-04-06 07:54 kreNote Added: 0004357 2019-04-09 11:07 geoffclare Note Added: 0004358 2019-04-09 11:09 geoffclare Note Edited: 0004358 2019-04-09 11:11 geoffclare Note Edited: 0004358 2019-04-09 11:13 geoffclare Note Edited: 0004358 2019-04-09 11:19 geoffclare Relationship added related to 0001211 ==
[1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1212 == Reported By:kre Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1212 Category: Shell and Utilities Type: Enhancement Request Severity: Objection Priority: normal Status: New Name: Robert Elz Organization: User Reference: Section:XCU 2.14 -- trap special builtin Page Number:2420 - 2423 Line Number:77484-5 (and more) Interp Status: --- Final Accepted Text: == Date Submitted: 2018-09-28 02:56 UTC Last Modified: 2019-04-06 07:54 UTC == Summary:Enhance trap command == -- (0004357) kre (reporter) - 2019-04-06 07:54 http://austingroupbugs.net/view.php?id=1212#c4357 -- Re http://austingroupbugs.net/view.php?id=1212#c4356 No, certainly nothing is needed as a special case for signals which default to ignored - those are not the same state in any case - explicitly ignoring a signal is a different state from simply doing nothing, which results in the signal being ignored (perhaps a subtle difference, but a difference nevertheless). I wouldn't use SIGCHLD as an example of that however, as while the effect on signal delivery of an ignored (SIG_IGN) SIGCHLD is the same as for SIGCHLD in its default state (SIG_DFL) being ignored can have other ramifications for the application. This does however raise two other interesting questions. First should the trap command (some enhanced trap command as proposed here) report a signal that was ignored upon entry to the shell as being ignored, or simply as being in its default state?I have no particular insightful answer to that one, and either would be reasonable. My gut tells me that the purpose of the command is to discover what earlier manipulations have been made in the script, so a function (or dot script, or whatever) can return the world to its entry state before finishing. If that's the case the signals ignored on entry (which the shell cannot manipulate anyway) would be irrelevant. However having those signals explicitly listed as ignored would not harm that usage, and would allow the script to discover that no matter how much it wants to receive a SIGxxx it cannot, because its parent invoked it with that signal ignored, and hence the script needs to either fail, or use some other method to handle whatever it needed the signal for (if it was just for synchronisation between its sub-shells, then it might simply pick a different signal to use). My implementation of this currently lists signals that were ignored on entry as being in the default state (or actually, whatever state the script attempted to set the signal into - whether or not that was actually effective) - but that could easily be changed if the overall opinion is that that would be better. This also raises an additional sub-issue of whether or not there should be some method to allow a script to trap a signal that was ignored on entry if it really needs to do that. C programs can do it, I see no particular reason why scripts should not have the option .. the only reason that I can see that it isn't done now, is that typical program behaviour used to be if (signal(SIGxxx, SIG_IGN) != SIG_IGN) signal(SIGxxx, xxx_trap); so that a signal which was ignored would stay that way (that's usually what is wanted) and as sh provided no method to do the test explicitly, so only provided that mechanism. But as it was always OK to restore the signal to its entry state (no test like above is done then) sh always explicitly tests the invocation signal state, as it has no other way to know whether a trap command is establishing a new trap or resetting to the earlier state. If we had the testing method, and an option to not do the test, but simply override an existing SIG_IGN (not previously set by the script) I don't see that it would do any harm - the current trap command would need to continue acting the way it always has of course. The second new issue mentioned above is more specific to SIGCHLD (though could also apply to other signals). If a script does trap '' SIGCHLD and the shell from that
[1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1212 == Reported By:kre Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1212 Category: Shell and Utilities Type: Enhancement Request Severity: Objection Priority: normal Status: New Name: Robert Elz Organization: User Reference: Section:XCU 2.14 -- trap special builtin Page Number:2420 - 2423 Line Number:77484-5 (and more) Interp Status: --- Final Accepted Text: == Date Submitted: 2018-09-28 02:56 UTC Last Modified: 2019-04-04 17:35 UTC == Summary:Enhance trap command == -- (0004356) shware_systems (reporter) - 2019-04-04 17:35 http://austingroupbugs.net/view.php?id=1212#c4356 -- Does it need to be a special case that the output for a trap whose default interpretation as a sigaction is to be ignored, such as SIGCHLD and SIGURG, shall be reported as if they were explicitly set to this if a handler action is not assigned, i.e.: >echo `trap -p CHLD` trap -- "" CHLD and not: trap -- - CHLD or is the first form reported only when an actual trap "" CHLD command has been entered? Issue History Date ModifiedUsername FieldChange == 2018-09-28 02:56 kreNew Issue 2018-09-28 02:56 kreName => Robert Elz 2018-09-28 02:56 kreSection => XCU 2.14 -- trap special builtin 2018-09-28 02:56 krePage Number => 2420 - 2423 2018-09-28 02:56 kreLine Number => 77484-5 (and more) 2019-04-04 17:35 shware_systems Note Added: 0004356 ==
[1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command
The following issue has been SUBMITTED. == http://austingroupbugs.net/view.php?id=1212 == Reported By:kre Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1212 Category: Shell and Utilities Type: Enhancement Request Severity: Objection Priority: normal Status: New Name: Robert Elz Organization: User Reference: Section:XCU 2.14 -- trap special builtin Page Number:2420 - 2423 Line Number:77484-5 (and more) Interp Status: --- Final Accepted Text: == Date Submitted: 2018-09-28 02:56 UTC Last Modified: 2018-09-28 02:56 UTC == Summary:Enhance trap command Description: The trap command, as it stands, is missing two useful functions 1) the ability to discover the current action for a particular condition 2) the ability to save the current state of all conditions (see issue 1211) Several shells have implemented a solution to (1) using a new -p option to trap (unfortunately, the output format, and so how it should be used, varies - but at least the mechanism is there). The NetBSD shell has a solution to (2) based upon that for (1), but as far as I know, no other shell has a solution to this, and the NetBSD shell is not in widespread enough use to standardise its mechanism yet. Hence, I am requesting that this issue be marked as "for the future" and retained (along with any notes it attracts, and possible different solutions) until we do have something that is ready to be included in the standard. And implementers - please do *something*... Also note, that for shells that have "trap -p" already, but treat it used with no conditions as identical to "trap" with no operands, that is not a useful feature (two ways to do the same thing) and changing the implementation of "trap -p" as suggested below will do no harm. Desired Action: In the SYNOPSIS, between lines 77484 and 77485 add a new form for the command trap -p [condition...] Then somewhere in the DESCRIPTION (probably after the paragraph about trap with no operands, starting on line 77514) add a new paragraph When the -p option is given the trap command shall write, in the same format used when no operands are given, a list of commands for each condition specified as an operand, or if no operands, other than the -p flag, are given, then for all possible conditions for which actions can be set in the shell, whether currently at their default values,or not. It is unspecified whether the values for SIGKILL and SIGSTOP can be obtained this way, but if those are included in trap -p output, the shell shall not object to them used as input provided that the action specified is the same as was, or would be, output by trap -p, and in this case no undefined results shall occur. Then change the example at line 77524 from save_traps=$(trap) to save_traps=$(trap -p) == Issue History Date ModifiedUsername FieldChange == 2018-09-28 02:56 kreNew Issue 2018-09-28 02:56 kreName => Robert Elz 2018-09-28 02:56 kreSection => XCU 2.14 -- trap special builtin 2018-09-28 02:56 krePage Number => 2420 - 2423 2018-09-28 02:56 kreLine Number => 77484-5 (and more) ==
