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/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
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
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
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,
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()
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
The following issue has been UPDATED.
==
http://austingroupbugs.net/view.php?id=1198
==
Reported By:geoffclare
Assigned To:
The following issue has been UPDATED.
==
http://austingroupbugs.net/view.php?id=472
==
Reported By:markh
Assigned To:ajosey
The following issue has been UPDATED.
==
http://austingroupbugs.net/view.php?id=1166
==
Reported By:zackw
Assigned To:
The following issue has been UPDATED.
==
http://austingroupbugs.net/view.php?id=953
==
Reported By:wpollock
Assigned To:
The following issue has been UPDATED.
==
http://austingroupbugs.net/view.php?id=1159
==
Reported By:scottcheloha
Assigned To:
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
28 matches
Mail list logo
