Chet and I can continue thus conversation off list, what is
being discussed now has nothing at all to do with anything
related to posix.
kre
On 5/13/22 5:37 PM, Robert Elz wrote:
Date:Sat, 14 May 2022 03:56:32 +0700
From:"Robert Elz via austin-group-l at The Open Group"
Message-ID: <2459.1652475...@jinx.noi.kre.to>
| | Show your work.
| I no longer remember the exact command I used (cannot
On 5/13/22 4:56 PM, Robert Elz wrote:
Date:Fri, 13 May 2022 11:22:20 -0400
From:Chet Ramey
Message-ID:
| Show your work.
|
| I tested this on macOS 12 and RHEL 7, using interactive shells with job
| control enabled,
That is likely the difference.
Date:Sat, 14 May 2022 03:56:32 +0700
From:"Robert Elz via austin-group-l at The Open Group"
Message-ID: <2459.1652475...@jinx.noi.kre.to>
| | Show your work.
| I no longer remember the exact command I used (cannot even locate the
| message you're quoting
Date:Fri, 13 May 2022 11:22:20 -0400
From:Chet Ramey
Message-ID:
| Show your work.
|
| I tested this on macOS 12 and RHEL 7, using interactive shells with job
| control enabled,
That is likely the difference. The question was about what happens when
job
On 5/5/22 7:46 AM, Geoff Clare via austin-group-l at The Open Group wrote:
[Robert intended to send the mail I'm replying to to the list, but it
was only sent to me. I've quoted it in full.]
Robert Elz wrote, on 05 May 2022:
This leaves just bash of the shells I have to test. bash is odd,
chet.ra...@case.edu wrote in
<217874a6-64d5-184b-68e8-0bedb322f...@case.edu>:
|On 5/13/22 10:27 AM, Geoff Clare via austin-group-l at The Open Group \
|wrote:
|> Chet Ramey wrote, on 13 May 2022:
|>> On 5/13/22 5:20 AM, Geoff Clare via austin-group-l at The Open Group \
|>> wrote:
|>>> The
On 5/13/22 10:27 AM, Geoff Clare via austin-group-l at The Open Group wrote:
Chet Ramey wrote, on 13 May 2022:
On 5/13/22 5:20 AM, Geoff Clare via austin-group-l at The Open Group wrote:
The definition of "Job" is:
A set of processes, comprising a shell pipeline, and any processes
Chet Ramey wrote, on 13 May 2022:
>
> On 5/13/22 5:20 AM, Geoff Clare via austin-group-l at The Open Group wrote:
>
> > The definition of "Job" is:
> >
> > A set of processes, comprising a shell pipeline, and any processes
> > descended from it, that are all in the same process group.
On 5/13/22 5:20 AM, Geoff Clare via austin-group-l at The Open Group wrote:
You are over reaching in the way you are reading that text.
I strongly disagree.
If you have to work that hard to make your case, it's a good indication
that the existing language is wrong -- or at least
On 5/12/22 10:03 AM, Geoff Clare via austin-group-l at The Open Group wrote:
The normative text relating to creation of job numbers/IDs is all
conditional on job control being enabled.
Where is that? It's not in the definition of Job ID, it's not in 2.9.3
Asynchronous Lists, it's not in the
On 5/11/22 6:31 PM, Robert Elz wrote:
| For neither the first nor the last time.
Including now.
People can disagree.
| > I think they should remain independent.
| Sure, I agree.
I don't. I cannot think of a single reason why the shell should be
forced to maintain two separate
On 5/11/22 6:56 PM, Robert Elz wrote:
| Maybe. And yet I can't recall ever receiving a bug about this.
[...]
The circumstances to provoke a problem need to be contrived.
Exactly. It's a largely hypothetical scenario.
--
``The lyf so short, the craft so long to lerne.'' -
Date:Fri, 13 May 2022 10:20:49 +0100
From:"Geoff Clare via austin-group-l at The Open Group"
Message-ID: <20220513092049.GB17043@localhost>
| [Robert Cc'ed this to austin-grou...@netbsd.org which presumably bounced.
| I'm taking that as indication that he
[Robert Cc'ed this to austin-grou...@netbsd.org which presumably bounced.
I'm taking that as indication that he intended it to go to this list,
and am quoting it in full.]
Robert Elz wrote, on 12 May 2022:
>
> | The standard needs to specify them separately because, as per the
> | mail I just
Robert Elz wrote, on 12 May 2022:
>
> | > I think they should remain independent.
> | Sure, I agree.
>
> I don't. I cannot think of a single reason why the shell should be
> forced to maintain two separate lists of its child processes. The jobs
> table needs to have them, so processes in
Chet Ramey wrote, on 11 May 2022:
>
> On 5/10/22 12:03 PM, Geoff Clare via austin-group-l at The Open Group wrote:
>
> >> I'd be interested in your reasoning. The standard simply says that jobs
> >> and kill (and wait should be added) work with job %X notation whether
> >> or not job control is
Date:Wed, 11 May 2022 09:58:38 -0400
From:"Chet Ramey via austin-group-l at The Open Group"
Message-ID: <4d0598b4-efb3-d5c2-1267-b8a807399...@case.edu>
| > It is already what the standard requires, and with good reason.
|
| Sure. It simply isn't what many
Date:Wed, 11 May 2022 09:17:15 -0400
From:"Chet Ramey via austin-group-l at The Open Group"
Message-ID: <573bc015-dd85-f86e-b89d-33a0bcc4b...@case.edu>
Again, apologies, still very little time for any of this.
| For neither the first nor the last time.
Including
chet.ra...@case.edu wrote in
<195c7c59-8328-4ddc-b936-345f34ab1...@case.edu>:
|On 5/10/22 12:03 PM, Geoff Clare via austin-group-l at The Open Group \
|wrote:
...
|So for the known IDs list, it's pretty much `wait' and `jobs', right?
Great words spoken easily.
--steffen
|
|Der Kragenbaer,
On 5/10/22 12:03 PM, Geoff Clare via austin-group-l at The Open Group wrote:
>> If jobs and kill work, you should probably add wait to this description, or
>> add a separate paragraph to the wait rationale.
>
> If it works with "wait" in all shells (that we care about), then I
> agree it would
On 5/10/22 11:50 AM, Geoff Clare via austin-group-l at The Open Group wrote:
> Chet Ramey wrote, on 06 May 2022:
>>
And last, also in this area, is the question of stopped jobs and the wait
command, and how those two are intended to interact.
>>>
>>> The wording in my current draft makes
On 5/10/22 11:17 AM, Geoff Clare via austin-group-l at The Open Group wrote:
>> Anyway, I agree with disallowing remove-before-prompting.
>
> Unfortunately that puts you in opposition to kre.
For neither the first nor the last time.
>> Or make it clear everywhere that removing a job from the
Chet Ramey wrote, on 06 May 2022:
>
> On 5/5/22 7:46 AM, Geoff Clare via austin-group-l at The Open Group wrote:
>
> > The fact that the jobs command works with job control disabled is
> > mentioned in the rationale on the jobs page:
> >
> > The jobs utility is not dependent on the job
Chet Ramey wrote, on 06 May 2022:
>
> > > And last, also in this area, is the question of stopped jobs and the wait
> > > command, and how those two are intended to interact.
> >
> > The wording in my current draft makes clear that wait waits for
> > processes to terminate. I could, if desired,
Chet Ramey wrote, on 06 May 2022:
>
> > There would seem to be two options to resolve this:
> >
> > A. Uphold the decision to disallow remove-before-prompting. This
> > would mean removing the conflicting text from set -b and updating the
> > justification on the wait page to something that
chet.ra...@case.edu wrote in
<88762e56-0276-f936-cf4c-d48c8ddc2...@case.edu>:
|On 4/29/22 4:23 PM, Robert Elz via austin-group-l at The Open Group wrote:
...
|> true & X=$!
...
|They're not jobs! A pid is a pid. It doesn't matter whether it's the pid of
|the job's controlling process (or
On 5/5/22 7:46 AM, Geoff Clare via austin-group-l at The Open Group wrote:
The fact that the jobs command works with job control disabled is
mentioned in the rationale on the jobs page:
The jobs utility is not dependent on the job control option, as
are the seemingly related bg and
On 5/3/22 6:52 AM, Geoff Clare via austin-group-l at The Open Group wrote:
Robert Elz wrote, on 30 Apr 2022:
| However, today it threw a last curve ball when I was working on an
| update to the description of set -b ...
How many shells actually implement that?
They all accept it as an
On 4/29/22 4:23 PM, Robert Elz via austin-group-l at The Open Group wrote:
| You can test this by doing
|
|true &
|
|wait $!; echo $?
|
| This should print 0. Then do the same, except with the first command
| changed to false &. That should print 1.
Yes, in
On 4/29/22 2:38 PM, Robert Elz via austin-group-l at The Open Group wrote:
| However, today it threw a last curve ball when I was working on an
| update to the description of set -b ...
How many shells actually implement that?
Bash does. I doubt anyone uses it.
| This conflicts
On 4/29/22 10:39 AM, Geoff Clare via austin-group-l at The Open Group wrote:
I'm responding to these messages in order; sorry if I cover ground that's
already been covered.
I've been gradually making progress on bug 1254 as a background task.
However, today it threw a last curve ball when I
[Robert intended to send the mail I'm replying to to the list, but it
was only sent to me. I've quoted it in full.]
Robert Elz wrote, on 05 May 2022:
>
> | > How many shells actually implement that?
> |
> | They all accept it as an option, but for some it seems to be a no-op.
>
> Oh yes,
Robert Elz wrote, on 30 Apr 2022:
>
> | However, today it threw a last curve ball when I was working on an
> | update to the description of set -b ...
>
> How many shells actually implement that?
They all accept it as an option, but for some it seems to be a no-op.
That's one of the changes
Date:Fri, 29 Apr 2022 20:11:55 +0100
From:"Harald van Dijk via austin-group-l at The Open Group"
Message-ID:
| >| It also appears that dash still implements remove-before-prompting.
|
| busybox ash and my shell do as well, but both are derived from dash
On 29/04/2022 19:38, Robert Elz via austin-group-l at The Open Group wrote:
Date:Fri, 29 Apr 2022 15:39:23 +0100
From:"Geoff Clare via austin-group-l at The Open Group"
Message-ID: <20220429143923.GA22521@localhost>
| It also appears that dash still
Date:Fri, 29 Apr 2022 15:39:23 +0100
From:"Geoff Clare via austin-group-l at The Open Group"
Message-ID: <20220429143923.GA22521@localhost>
Sorry, been too busy to participate here much recently, will catch up
someday soon (I hope).
| However, today it threw a
It appears to me the set -b wording needs updating, to clarify "may remove the
job's process ID" is intended to exclude the blocking circumstances listed, and
since it's a "may", not "shall", whether those exclusions are handled properly
now is more a quality of implementation than conformance
I've been gradually making progress on bug 1254 as a background task.
However, today it threw a last curve ball when I was working on an
update to the description of set -b ...
That description includes this near the end:
When the shell notifies the user a job has been completed, it may
39 matches
Mail list logo
