The following issue has a resolution that has been APPLIED.
==
https://austingroupbugs.net/view.php?id=1212
==
Reported By:kre
Assigned To:
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"
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
>
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
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
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
--- 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
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
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
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
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
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
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 ''
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.
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
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
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
> |
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
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
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
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
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
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
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
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
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
>
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
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
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
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
>>
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
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
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):
| >
| >
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
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
A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=1212
==
Reported By:kre
Assigned To:
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
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
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
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,
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
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
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
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
The following issue has been RESOLVED.
==
http://austingroupbugs.net/view.php?id=1212
==
Reported By:kre
Assigned To:
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
> >>
> 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
>>
> --
> (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
A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=1212
==
Reported By:kre
Assigned To:
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
> --
> (0004359) joerg (reporter) - 2019-04-09 13:32
> http://austingroupbugs.net/view.php?id=1212#c4359
> --
> Hi Geoff, your text does not include an
A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=1212
==
Reported By:kre
Assigned To:
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
The following issue has been set as RELATED TO issue 0001211.
==
http://austingroupbugs.net/view.php?id=1212
==
Reported By:kre
Assigned To:
A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=1212
==
Reported By:kre
Assigned To:
A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=1212
==
Reported By:kre
Assigned To:
The following issue has been SUBMITTED.
==
http://austingroupbugs.net/view.php?id=1212
==
Reported By:kre
Assigned To:
57 matches
Mail list logo
