On 1/31/24 2:35 PM, Robert Elz wrote:
| Not quite. `new' in this sense is the opposite of `anything in the past'
| as Dale described it -- already notified and removed from the jobs list.
I guess the part about bash that I am not understanding here is how the
"already notified" works. T
On Thu, Feb 1, 2024, 09:09 alex xmb sw ratchev wrote:
>
>
> On Wed, Jan 31, 2024, 20:36 Robert Elz wrote:
>
>> Date:Wed, 31 Jan 2024 11:35:57 -0500
>> From:Chet Ramey
>> Message-ID: <1e50aa99-8d53-4cdf-ba5e-6aaf3ccc6...@case.edu>
>>
>> | Not quite. `new' in this s
On Wed, Jan 31, 2024, 20:36 Robert Elz wrote:
> Date:Wed, 31 Jan 2024 11:35:57 -0500
> From:Chet Ramey
> Message-ID: <1e50aa99-8d53-4cdf-ba5e-6aaf3ccc6...@case.edu>
>
> | Not quite. `new' in this sense is the opposite of `anything in the
> past'
> | as Dale descr
Date:Wed, 31 Jan 2024 11:35:57 -0500
From:Chet Ramey
Message-ID: <1e50aa99-8d53-4cdf-ba5e-6aaf3ccc6...@case.edu>
| Not quite. `new' in this sense is the opposite of `anything in the past'
| as Dale described it -- already notified and removed from the jobs list.
On 1/30/24 12:40 PM, Robert Elz wrote:
| since this was the way -n worked orginally, before it started
| paying attention to pid arguments.
I'm not sure what the "this" is there, if you meant as I described it
in my answer to your rhetorical question, viz:
Find, or if there are n
On 1/30/24 4:28 PM, Chet Ramey wrote:
It's not a bug, bash has allowed multiple waits for the same pid for
decades. bash works the way posix says it should for wait (without -n)
in posix mode.
I think this is a bug in bash posix mode, actually. `wait -n' should
remove the job completely, since
On 1/30/24 2:30 PM, Robert Elz wrote:
| If wait -n
| looked at terminated processes you'd return jobs repeatedly and
| possibly end up in an infinite loop.
That's another bash bug, POSIX says:
It's not a bug, bash has allowed multiple waits for the same pid for
decades. bash works th
Date:Tue, 30 Jan 2024 10:14:10 -0500
From:Steven Pelley
Message-ID:
| If wait -n
| looked at terminated processes you'd return jobs repeatedly and
| possibly end up in an infinite loop.
That's another bash bug, POSIX says:
Once a process ID that is k
Date:Tue, 30 Jan 2024 09:16:47 -0500
From:Chet Ramey
Message-ID: <95841ed3-ec4f-4b17-802c-86e560b58...@case.edu>
| since this was the way -n worked orginally, before it started
| paying attention to pid arguments.
I'm not sure what the "this" is there, if you mea
Apologies for a typo:
With the discussed change this would return 44080: 1 in an endless loop.
1, not 0
On Tue, Jan 30, 2024 at 10:14 AM Steven Pelley wrote:
>
> > OK. Can you think of a use case that would break if wait -n looked at
> > terminated processes?
>
> Yes. If one were to start a numb
On 1/30/24 10:14 AM, Steven Pelley wrote:
OK. Can you think of a use case that would break if wait -n looked at
terminated processes?
Yes. If one were to start a number of bg jobs and repeatedly send the
list of pids to wait -n (probably redirecting stderr to /dev/null to
ignore messages about
> OK. Can you think of a use case that would break if wait -n looked at
> terminated processes?
Yes. If one were to start a number of bg jobs and repeatedly send the
list of pids to wait -n (probably redirecting stderr to /dev/null to
ignore messages about unknown jobs) today you'd process the jo
On 1/30/24 9:11 AM, Steven Pelley wrote:
It does look in the table of saved exit statuses, returning 1.
It doesn't. In this case, the code path it follows marks the job as dead
but doesn't mark it as notified (since it exited normally), so it's still
in the jobs list when `wait -n' is called, a
On 1/29/24 3:49 PM, Robert Elz wrote:
Date:Mon, 29 Jan 2024 12:07:53 -0500
From:Chet Ramey
Message-ID:
| What does `wait -n' without job arguments mean?
Find, or if there are none already, wait*(2) for, a process (job technically)
that has changed state (ter
> > It does look in the table of saved exit statuses, returning 1.
>
> It doesn't. In this case, the code path it follows marks the job as dead
> but doesn't mark it as notified (since it exited normally), so it's still
> in the jobs list when `wait -n' is called, and available for returning.
> Tha
On 1/28/24 10:26 PM, Dale R. Worley wrote:
Chet Ramey writes:
echo "wait -n $pid return code $? @${SECONDS} (BUG)"
The job isn't in the jobs table because you've already been notified about
it and it's not `new', you get the unknown job error status.
The man page gives a lot of details and
Date:Mon, 29 Jan 2024 12:07:53 -0500
From:Chet Ramey
Message-ID:
| What does `wait -n' without job arguments mean?
Find, or if there are none already, wait*(2) for, a process (job technically)
that has changed state (terminated in POSIX, and one day in the NetBSD
On 1/29/24 7:54 AM, Andreas Schwab wrote:
On Jan 29 2024, Robert Elz wrote:
I always wondered why the option was 'n'
n = next?
Yes: the original implementation polled the non-terminated background jobs
and returned when one of them exited.
--
``The lyf so short, the craft so long to lerne.
On 1/29/24 12:33 PM, Chet Ramey wrote:
You should have. You told me about your implementation using `-n' in
10/2017, long before I implemented it (4/2020).
Sorry, this is my mistake. That was a different feature. Bash implemented
`wait -n' first.
For those wondering, the `different feature'
On 1/29/24 12:07 PM, Chet Ramey wrote:
On 1/29/24 7:12 AM, Robert Elz wrote:
Date: Sun, 28 Jan 2024 18:21:42 -0500
From: Chet Ramey
Message-ID: <3347f790-529b-4bee-91fd-de39bed3f...@case.edu>
| because `wait -n' doesn't look in the table
| of saved statuses
On 1/29/24 7:12 AM, Robert Elz wrote:
Date:Sun, 28 Jan 2024 18:21:42 -0500
From:Chet Ramey
Message-ID: <3347f790-529b-4bee-91fd-de39bed3f...@case.edu>
| because `wait -n' doesn't look in the table
| of saved statuses -- its job is to wait for `new' jobs to
On 1/28/24 7:19 PM, Steven Pelley wrote:
Thank you Chet for your thorough reply.
You make a few comments about differences in output (stderr for not
finding a job, notifications for jobs terminating) and in all cases I
believe you are correct. Let's assume job control is disabled.
OK, but rem
On Mon, Jan 29, 2024 at 08:52:37PM +0700, Robert Elz wrote:
> Date:Mon, 29 Jan 2024 13:54:10 +0100
> From:Andreas Schwab
> Message-ID:
>
> | n = next?
This was my assumption as well.
> That would be a reasonable interpretation, I guess, but
> unfortunately not on
Date:Mon, 29 Jan 2024 13:54:10 +0100
From:Andreas Schwab
Message-ID:
| n = next?
That would be a reasonable interpretation, I guess, but
unfortunately not one which helps the current question,
as it doesn't answer "next what?" It could be "the next
of these proc
On Jan 29 2024, Robert Elz wrote:
> I always wondered why the option was 'n'
n = next?
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Date:Sun, 28 Jan 2024 18:21:42 -0500
From:Chet Ramey
Message-ID: <3347f790-529b-4bee-91fd-de39bed3f...@case.edu>
| because `wait -n' doesn't look in the table
| of saved statuses -- its job is to wait for `new' jobs to terminate, not
| ones that have already bee
On Monday, January 29, 2024, Greg Wooledge wrote:
>
> Anyway... a script writer who has a basic familiarity with wait(2) and
> who reads about "wait -n" will probably assume that wait -n will return
> immediately if a child process has already terminated and hasn't been
> "pseudo-reaped" by a prev
On Sun, Jan 28, 2024 at 10:26:27PM -0500, Dale R. Worley wrote:
> The man page doesn't make clear that if you don't specify "-n" and do
> supply ids and one of them has already terminated, you'll get its status
> (from the terminated table); the wording suggests that "wait" will
> always *wait for*
Chet Ramey writes:
>> echo "wait -n $pid return code $? @${SECONDS} (BUG)"
>
> The job isn't in the jobs table because you've already been notified about
> it and it's not `new', you get the unknown job error status.
The man page gives a lot of details and I'm trying to digest them into a
structu
Thank you Chet for your thorough reply.
You make a few comments about differences in output (stderr for not
finding a job, notifications for jobs terminating) and in all cases I
believe you are correct. Let's assume job control is disabled.
> >
> > I expect the line ending (BUG) to indicate a re
On 1/22/24 11:30 AM, Steven Pelley wrote:
I've tried:
killing with SIGTERM and SIGALRM
killing from the test script, a subshell, and another terminal. I
don't believe this is related to kill being a builtin.
enabling job control (set -m)
bash versions 4.4.12, 5.2.15, 5.2.21. All linux arm64
On Mon, Jan 22, 2024 at 8:13 PM Steven Pelley wrote:
>
> Hello,
> I've encountered what I believe is a bug in bash's "wait -n". wait -n
> fails to return for processes that terminate due to a signal prior to
> calling wait -n. Instead, it returns 127 with an error that the
> process id cannot be
Apologies for a quick double post, strace is fairly straightforward
and confirms that bash is properly reaping the killed processes. This
isn't a matter of the wait syscall failing to return the signaled
child process.
Running the test from my original post and producing:
TEST: KILL PRIOR TO wait
> In the first case, if the subprocess N has terminated, its report is
> still queued and "wait" retrieves it. In the second case, if the
> subprocess N has terminated, it doesn't exist and as the manual page
> says "If id specifies a non-existent process or job, the return status
> is 127."
>
> W
Steven Pelley writes:
> wait -n
> fails to return for processes that terminate due to a signal prior to
> calling wait -n. Instead, it returns 127 with an error that the
> process id cannot be found. Calling wait (without -n) then
> returns its exit code (e.g., 143).
My understanding is that t
35 matches
Mail list logo
