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: pthread_t and thrd_t
On 4/17/2019 3:53 PM, Alan Coopersmith wrote: > On 4/17/19 8:58 AM, Geoff Clare wrote: >> So glibc will conform if we require that pthread_t and thrd_t are >> defined as the same type, but does anyone know of an implementation >> that has pthreads and C11/C17 threads, with pthread_t and thrd_t defined >> as different types? > Not here, Oracle Solaris 11.4 has the same type for both: > > /usr/include/sys/types.h: > typedef unsigned intuint_t; > typedefuint_t pthread_t; /* = thread_t in thread.h */ > > /usr/include/threads.h: > typedef unsigned int thrd_t; > > To see the full headers for yourself: > > /usr/include/sys/types.h: > curl -s > http://pkg.oracle.com/solaris/release/file/0/55ae99dec04f09e8fe9963d87d24ae371c8e85b9 > | gzcat | less > > /usr/include/threads.h: > curl -s > http://pkg.oracle.com/solaris/release/file/0/183228c541fb3e2b2b6c710fa46964d94ee259a8 > | gzcat | less > > (For others, substitute the hash listed at the beginning of the line after > "file" for the given header file listed in > > http://pkg.oracle.com/solaris/release/manifest/0/system%2Fheader@11.4%2C5.11-11.4.0.0.1.15.0%3A20180817T003001Z > ) > RTEMS uses the Newlib C library like Cygwin. The C11 threads header is from FreeBSD. The RTEMS pthread_t and thrd_t both are defined to uint32_t. Newlib's pthread.h, sys/_pthreadtypes.h, threads.h, and machine/threads.h can be browsed here: https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=tree;f=newlib/libc/include;h=448a39cdb98eafe471a761e2fbfecf8dfa41fa31;hb=HEAD RTEMS uses the FreeBSD implementation of these services and that's here: https://git.rtems.org/rtems/tree/cpukit/libstdthreads Also, for RTEMS, the C11 threads are not in libc, they are part of the RTEMS threading services library. --joel sherrill RTEMS
Re: pthread_t and thrd_t
On 4/17/19 8:58 AM, Geoff Clare wrote: > So glibc will conform if we require that pthread_t and thrd_t are > defined as the same type, but does anyone know of an implementation > that has pthreads and C11/C17 threads, with pthread_t and thrd_t defined > as different types? Not here, Oracle Solaris 11.4 has the same type for both: /usr/include/sys/types.h: typedef unsigned intuint_t; typedefuint_t pthread_t; /* = thread_t in thread.h */ /usr/include/threads.h: typedef unsigned int thrd_t; To see the full headers for yourself: /usr/include/sys/types.h: curl -s http://pkg.oracle.com/solaris/release/file/0/55ae99dec04f09e8fe9963d87d24ae371c8e85b9 | gzcat | less /usr/include/threads.h: curl -s http://pkg.oracle.com/solaris/release/file/0/183228c541fb3e2b2b6c710fa46964d94ee259a8 | gzcat | less (For others, substitute the hash listed at the beginning of the line after "file" for the given header file listed in http://pkg.oracle.com/solaris/release/manifest/0/system%2Fheader@11.4%2C5.11-11.4.0.0.1.15.0%3A20180817T003001Z ) -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/alanc
Re: pthread_t and thrd_t
for Android, i've been sitting this one out waiting for it to actually matter (i wasn't aware glibc had added this API --- i thought musl was the only implementation to date), but my intention is to just reuse the pthread types, not least because that lets me offer this in a backwards compatible way to old versions of Android that shipped before this stuff gets added. (it's not in Android Q.) looks like while i was sleeping FreeBSD implemented it too: https://github.com/freebsd/freebsd/tree/master/lib/libstdthreads /me wonders why no-one seems to have used pthread_key_t for tss_t, even when they have reused the pthreads types for the other stuff... On Wed, Apr 17, 2019 at 8:59 AM Geoff Clare wrote: > > I'm working on drafting the changes to align POSIX with C17 and I > have a question for the group about the types pthread_t and thrd_t. > > It seems to me that it would be best if these are defined as the > same type, so that there are no complications with calling both > pthread_self() and thrd_current() from: > > * The initial thread. > > * Threads created using pthread_create(). > > * Threads created using thrd_create(). > > * Threads created via a SIGEV_THREAD notification. > > If pthread_t and thrd_t were allowed to be different types, I > suppose this could be made to work by giving the initial thread > two IDs, one of each type, and forbidding calls to pthread_self() > from threads created using thrd_create() or calls to thrd_current() > from threads created using pthread_create() or via a SIGEV_THREAD > notification. However, this would be a nightmare for third-party > libraries if they want to use pthread_self() or thrd_current() in > a thread they don't create themselves. (I suppose they would have > to have two flavours of the library, one for pthreads and one for > C11/C17 threads.) > > I had a look at the current glibc source, and was initially alarmed > to see that it defines thrd_t as unsigned long int, since I was > sure I could remember pthread_t being a structure pointer, but I > see that it now has pthread_t as unsigned long int as well: > > https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=sysdeps/nptl/threads.h;hb=HEAD > > https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=sysdeps/nptl/bits/pthreadtypes.h;hb=HEAD > > So glibc will conform if we require that pthread_t and thrd_t are > defined as the same type, but does anyone know of an implementation > that has pthreads and C11/C17 threads, with pthread_t and thrd_t defined > as different types? > > -- > Geoff Clare > The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England >
RE: pthread_t and thrd_t
My implementation defines both as pointers, not int's, as 'typedef thrd_t pthread_t;'. Since threads.h is 99% a subset of pthreads.h, I see no reason to have them be different types, even as a breaking change. What is missing is in pthreads.h, to account for the new attributes C11 introduced, at least to mention them if support isn't going to be added.The major hassle I see is POSIX wants the the threading stuff in libpthread, and C11 wants it in libc if the threading option is enabled. IMO C11 should have let interfaces in optional headers all be in header-specific libraries or libc, as an implentation-defined choice, but they didn't. On Wednesday, April 17, 2019 Geoff Clare wrote: I'm working on drafting the changes to align POSIX with C17 and I have a question for the group about the types pthread_t and thrd_t. It seems to me that it would be best if these are defined as the same type, so that there are no complications with calling both pthread_self() and thrd_current() from: * The initial thread. * Threads created using pthread_create(). * Threads created using thrd_create(). * Threads created via a SIGEV_THREAD notification. If pthread_t and thrd_t were allowed to be different types, I suppose this could be made to work by giving the initial thread two IDs, one of each type, and forbidding calls to pthread_self() from threads created using thrd_create() or calls to thrd_current() from threads created using pthread_create() or via a SIGEV_THREAD notification. However, this would be a nightmare for third-party libraries if they want to use pthread_self() or thrd_current() in a thread they don't create themselves. (I suppose they would have to have two flavours of the library, one for pthreads and one for C11/C17 threads.) I had a look at the current glibc source, and was initially alarmed to see that it defines thrd_t as unsigned long int, since I was sure I could remember pthread_t being a structure pointer, but I see that it now has pthread_t as unsigned long int as well: https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=sysdeps/nptl/threads.h;hb=HEAD https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=sysdeps/nptl/bits/pthreadtypes.h;hb=HEAD So glibc will conform if we require that pthread_t and thrd_t are defined as the same type, but does anyone know of an implementation that has pthreads and C11/C17 threads, with pthread_t and thrd_t defined as different types? -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
pthread_t and thrd_t
I'm working on drafting the changes to align POSIX with C17 and I have a question for the group about the types pthread_t and thrd_t. It seems to me that it would be best if these are defined as the same type, so that there are no complications with calling both pthread_self() and thrd_current() from: * The initial thread. * Threads created using pthread_create(). * Threads created using thrd_create(). * Threads created via a SIGEV_THREAD notification. If pthread_t and thrd_t were allowed to be different types, I suppose this could be made to work by giving the initial thread two IDs, one of each type, and forbidding calls to pthread_self() from threads created using thrd_create() or calls to thrd_current() from threads created using pthread_create() or via a SIGEV_THREAD notification. However, this would be a nightmare for third-party libraries if they want to use pthread_self() or thrd_current() in a thread they don't create themselves. (I suppose they would have to have two flavours of the library, one for pthreads and one for C11/C17 threads.) I had a look at the current glibc source, and was initially alarmed to see that it defines thrd_t as unsigned long int, since I was sure I could remember pthread_t being a structure pointer, but I see that it now has pthread_t as unsigned long int as well: https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=sysdeps/nptl/threads.h;hb=HEAD https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=sysdeps/nptl/bits/pthreadtypes.h;hb=HEAD So glibc will conform if we require that pthread_t and thrd_t are defined as the same type, but does anyone know of an implementation that has pthreads and C11/C17 threads, with pthread_t and thrd_t defined as different types? -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
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
[1003.1(2016)/Issue7+TC2 0001198]: Comparison of numeric string values in awk
The following issue has been UPDATED. == http://austingroupbugs.net/view.php?id=1198 == Reported By:geoffclare Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1198 Category: Shell and Utilities Type: Error Severity: Objection Priority: normal Status: Interpretation Required Name: Geoff Clare Organization: The Open Group User Reference: Section:awk Page Number:2489 Line Number:80031 Interp Status: Approved Final Accepted Text:See http://austingroupbugs.net/view.php?id=1198#c4320. == Date Submitted: 2018-08-07 10:40 UTC Last Modified: 2019-04-17 10:52 UTC == Summary:Comparison of numeric string values in awk == -- (0004369) agadmin (administrator) - 2019-04-17 10:52 http://austingroupbugs.net/view.php?id=1198#c4369 -- Interpretation approved: 17 April 2019 Issue History Date ModifiedUsername FieldChange == 2018-08-07 10:40 geoffclare New Issue 2018-08-07 10:40 geoffclare Name => Geoff Clare 2018-08-07 10:40 geoffclare Organization => The Open Group 2018-08-07 10:40 geoffclare Section => awk 2018-08-07 10:40 geoffclare Page Number => 2489 2018-08-07 10:40 geoffclare Line Number => 80031 2018-08-07 10:40 geoffclare Interp Status => --- 2019-03-14 15:45 Don Cragun Note Added: 0004320 2019-03-14 15:46 Don Cragun Final Accepted Text => See http://austingroupbugs.net/view.php?id=1198#c4320. 2019-03-14 15:46 Don Cragun Status New => Interpretation Required 2019-03-14 15:46 Don Cragun Resolution Open => Accepted As Marked 2019-03-14 15:46 Don Cragun Description Updated 2019-03-14 15:46 Don Cragun Tag Attached: tc3-2008 2019-03-14 15:55 Don Cragun Note Edited: 0004320 2019-03-16 06:32 agadminInterp Status--- => Proposed 2019-03-16 06:32 agadminNote Added: 0004325 2019-04-17 10:52 agadminInterp StatusProposed => Approved 2019-04-17 10:52 agadminNote Added: 0004369 ==
[1003.1(2008)/Issue 7 0000472]: strftime %C does not account for sign character
The following issue has been UPDATED. == http://austingroupbugs.net/view.php?id=472 == Reported By:markh Assigned To:ajosey == Project:1003.1(2008)/Issue 7 Issue ID: 472 Category: System Interfaces Type: Error Severity: Objection Priority: normal Status: Interpretation Required Name: Mark Harris Organization: User Reference: Section:strftime Page Number:2008 Line Number:63559 Interp Status: Approved Final Accepted Text:see http://austingroupbugs.net/view.php?id=472#c4270 == Date Submitted: 2011-07-07 08:37 UTC Last Modified: 2019-04-17 10:52 UTC == Summary:strftime %C does not account for sign character == Relationships ID Summary -- has duplicate 0001184 strftime %C padding character unspecified == -- (0004368) agadmin (administrator) - 2019-04-17 10:52 http://austingroupbugs.net/view.php?id=472#c4368 -- Interpretation approved: 17 April 2019 Issue History Date ModifiedUsername FieldChange == 2011-07-07 08:37 markh New Issue 2011-07-07 08:37 markh Status New => Under Review 2011-07-07 08:37 markh Assigned To => ajosey 2011-07-07 08:37 markh Name => Mark Harris 2011-07-07 08:37 markh Section => strftime 2011-07-07 08:37 markh Page Number => 2008 2011-07-07 08:37 markh Line Number => 63559 2011-07-07 11:36 geoffclare Note Added: 886 2011-07-28 07:32 markh Note Added: 892 2011-08-11 15:38 eblake Note Added: 936 2011-08-11 15:40 eblake Interp Status => --- 2011-08-11 15:40 eblake Final Accepted Text => see http://austingroupbugs.net/view.php?id=472#c936 2011-08-11 15:40 eblake Status Under Review => Resolved 2011-08-11 15:40 eblake Resolution Open => Accepted As Marked 2011-08-11 15:40 eblake Tag Attached: issue8 2011-08-11 15:41 eblake Interp Status--- => Pending 2011-08-11 18:08 Don Cragun Status Resolved => Interpretation Required 2012-06-29 16:19 ajosey Interp StatusPending => Proposed 2012-06-29 16:19 ajosey Note Added: 0001301 2012-08-30 09:11 ajosey Interp StatusProposed => Approved 2012-08-30 09:11 ajosey Note Added: 0001342 2019-02-21 17:29 eblake Relationship added related to 0001184 2019-02-25 16:57 nick Resolution Accepted As Marked => Reopened 2019-02-25 17:05 nick Note Added: 0004266 2019-02-28 14:43 geoffclare Note Added: 0004270 2019-02-28 14:44 geoffclare Tag Detached: issue8 2019-02-28 16:32 geoffclare Interp StatusApproved => Pending 2019-02-28 16:32 geoffclare Final Accepted Text see http://austingroupbugs.net/view.php?id=472#c936 => see http://austingroupbugs.net/view.php?id=472#c4270 2019-02-28 16:32 geoffclare Resolution Reopened => Accepted As Marked 2019-02-28 16:32 geoffclare Tag Attached: tc3-2008 2019-02-28 16:36 Don Cragun Relationship replacedhas duplicate 0001184 2019-02-28 16:40 geoffclare Note Edited: 936 2019-03-12 14:05 agadminInterp StatusPending => Proposed 2019-03-12 14:05 agadminNote Added: 0004316 2019-04-17 10:52 agadminInterp StatusProposed => Approved 2019-04-17 10:52
[1003.1(2016)/Issue7+TC2 0001166]: Case variants needed for strftime %b as well as %B
The following issue has been UPDATED. == http://austingroupbugs.net/view.php?id=1166 == Reported By:zackw Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1166 Category: System Interfaces Type: Enhancement Request Severity: Comment Priority: normal Status: Interpretation Required Name: Zack Weinberg Organization: User Reference: Section:strftime Page Number:? Line Number:? Interp Status: Approved Final Accepted Text:See http://austingroupbugs.net/view.php?id=1166#c4237. == Date Submitted: 2017-10-27 20:11 UTC Last Modified: 2019-04-17 10:52 UTC == Summary:Case variants needed for strftime %b as well as %B == Relationships ID Summary -- related to 258 strftime needs an %EB specifier == -- (0004367) agadmin (administrator) - 2019-04-17 10:52 http://austingroupbugs.net/view.php?id=1166#c4367 -- Interpretation approved: 17 April 2019 Issue History Date ModifiedUsername FieldChange == 2017-10-27 20:11 zackw New Issue 2017-10-27 20:11 zackw Name => Zack Weinberg 2017-10-27 20:11 zackw Section => strftime 2017-10-27 20:11 zackw Page Number => ? 2017-10-27 20:11 zackw Line Number => ? 2017-10-27 21:02 shware_systems Note Added: 0003872 2017-10-27 21:24 zackw Note Added: 0003873 2017-10-27 22:53 shware_systems Note Added: 0003874 2019-01-31 16:31 nick Relationship added related to 258 2019-01-31 17:08 Don Cragun Note Added: 0004237 2019-01-31 17:09 Don Cragun Interp Status => Pending 2019-01-31 17:09 Don Cragun Final Accepted Text => See http://austingroupbugs.net/view.php?id=1166#c4237. 2019-01-31 17:09 Don Cragun Status New => Interpretation Required 2019-01-31 17:09 Don Cragun Resolution Open => Accepted As Marked 2019-01-31 17:10 Don Cragun Tag Attached: c99 2019-01-31 17:10 Don Cragun Tag Attached: issue8 2019-02-07 17:18 agadminInterp StatusPending => Proposed 2019-02-07 17:18 agadminNote Added: 0004244 2019-04-17 10:52 agadminInterp StatusProposed => Approved 2019-04-17 10:52 agadminNote Added: 0004367 ==
[1003.1(2013)/Issue7+TC1 0000953]: Alias expansion is under-specified
The following issue has been UPDATED. == http://austingroupbugs.net/view.php?id=953 == Reported By:wpollock Assigned To:ajosey == Project:1003.1(2013)/Issue7+TC1 Issue ID: 953 Category: Shell and Utilities Type: Clarification Requested Severity: Objection Priority: normal Status: Interpretation Required Name: Wayne Pollock Organization: User Reference: Section:2.3.1 Alias Substitution Page Number:2322 Line Number:73690-73705 Interp Status: Approved Final Accepted Text:See http://austingroupbugs.net/view.php?id=953#c4214 == Date Submitted: 2015-06-04 00:22 UTC Last Modified: 2019-04-17 10:52 UTC == Summary:Alias expansion is under-specified == Relationships ID Summary -- related to 736 grammatically accept zero or more Shell... related to 0001048 deprecate alias and unalias related to 0001055 unspecified how much is parsed before e... == -- (0004366) agadmin (administrator) - 2019-04-17 10:52 http://austingroupbugs.net/view.php?id=953#c4366 -- Interpretation approved: 17 April 2019 Issue History Date ModifiedUsername FieldChange == 2015-06-04 00:22 wpollock New Issue 2015-06-04 00:22 wpollock Status New => Under Review 2015-06-04 00:22 wpollock Assigned To => ajosey 2015-06-04 00:22 wpollock Name => Wayne Pollock 2015-06-04 00:22 wpollock Section => 2.3.1 Alias Substitution 2015-06-04 09:26 joerg Note Added: 0002694 2016-02-04 17:01 Don Cragun Page Number => 2322 2016-02-04 17:01 Don Cragun Line Number => 73690-73705 2016-02-04 17:01 Don Cragun Interp Status => --- 2016-02-04 17:04 Don Cragun Project 1003.1(2008)/Issue 7 => 1003.1(2013)/Issue7+TC1 2016-03-04 09:49 joerg Note Added: 0003089 2016-03-04 09:50 joerg Note Edited: 0003089 2016-03-04 11:39 joerg Note Edited: 0003089 2016-03-04 11:40 joerg Note Edited: 0003089 2016-03-04 15:11 joerg Note Edited: 0003089 2016-03-31 16:29 rhansenNote Added: 0003113 2016-03-31 16:30 rhansenNote Edited: 0003113 2016-03-31 16:32 nick Note Edited: 0003113 2016-03-31 16:33 nick Interp Status--- => Pending 2016-03-31 16:33 nick Final Accepted Text => See bugnote: 3113 2016-03-31 16:33 nick Status Under Review => Interpretation Required 2016-03-31 16:33 nick Resolution Open => Accepted As Marked 2016-03-31 16:33 nick Final Accepted Text See bugnote: 3113 => See http://austingroupbugs.net/view.php?id=953#c3113 2016-03-31 16:33 nick Note Edited: 0003113 2016-03-31 16:34 nick Tag Attached: tc3-2008 2016-03-31 16:34 rhansenNote Edited: 0003113 2016-03-31 16:40 rhansenNote Edited: 0003113 2016-04-01 12:29 ajosey Interp StatusPending => Proposed 2016-04-01 12:29 ajosey Note Added: 0003116 2016-04-10 22:09 jilles Note Added: 0003148 2016-04-11 14:31 chet_ramey Note Added: 0003149 2016-04-11 20:59 shware_systems Note Added: 0003150 2016-04-12 08:58 joerg Note Added: 0003151 2016-04-12 12:58 chet_ramey Note Added: 0003152
[1003.1(2016)/Issue7+TC2 0001159]: Is termination after receipt of SIGINT in dd(1) an error?
The following issue has been UPDATED. == http://austingroupbugs.net/view.php?id=1159 == Reported By:scottcheloha Assigned To:ajosey == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1159 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: Interpretation Required Name: Scott Cheloha Organization: User Reference: Section:dd(1) Page Number:2646 Line Number:86094-86096 Interp Status: Pending Final Accepted Text:See http://austingroupbugs.net/view.php?id=1159#c4216 == Date Submitted: 2017-08-16 16:20 UTC Last Modified: 2019-04-17 09:39 UTC == Summary:Is termination after receipt of SIGINT in dd(1) an error? == -- (0004365) geoffclare (manager) - 2019-04-17 09:39 http://austingroupbugs.net/view.php?id=1159#c4365 -- Looks like the Interp Status field was mistakenly set to "Proposed" when this bug was resolved. Setting it to "Pending". Issue History Date ModifiedUsername FieldChange == 2017-08-16 16:20 scottcheloha New Issue 2017-08-16 16:20 scottcheloha Status New => Under Review 2017-08-16 16:20 scottcheloha Assigned To => ajosey 2017-08-16 16:20 scottcheloha Name => Scott Cheloha 2017-08-16 16:20 scottcheloha Section => dd(1) 2017-08-16 16:20 scottcheloha Page Number => -- 2017-08-16 16:20 scottcheloha Line Number => -- 2017-08-16 16:21 scottcheloha Summary Is termination after receipt of SIGINT an error? => Is termination after receipt of SIGINT in dd(1) an error? 2019-01-14 15:42 nick Page Number -- => 2646 2019-01-14 15:42 nick Line Number -- => 86094-86096 2019-01-14 15:42 nick Interp Status => --- 2019-01-17 15:55 geoffclare Project 1003.1(2008)/Issue 7 => 1003.1(2016)/Issue7+TC2 2019-01-21 16:51 eblake Note Added: 0004216 2019-01-21 16:52 eblake Interp Status--- => Proposed 2019-01-21 16:52 eblake Final Accepted Text => See bugnote#4216 2019-01-21 16:52 eblake Status Under Review => Interpretation Required 2019-01-21 16:52 eblake Resolution Open => Accepted As Marked 2019-01-21 16:53 eblake Final Accepted Text See bugnote#4216 => See http://austingroupbugs.net/view.php?id=1159#c4216 2019-01-21 16:59 Don Cragun Note Edited: 0004216 2019-01-21 17:05 Don Cragun Tag Attached: tc3-2008 2019-04-17 09:39 geoffclare Interp StatusProposed => Pending 2019-04-17 09:39 geoffclare Note Added: 0004365 ==
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
