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,
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
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
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
On Tue, Jan 30, 2024 at 10:04 AM Andreas Schwab wrote:
> The command is doing exactly what it is documented to do, that is do all
> of the shell word expansions.
>
Quote Removal shows up as a subsection of the Shell Expansion section in
the manual, but it doesn't show up in the list of
On 1/30/24 10:42 AM, Kerin Millar wrote:
On Tue, 30 Jan 2024 10:34:28 -0500
Chet Ramey wrote:
On 1/30/24 10:29 AM, Kerin Millar wrote:
I'm not sure that this is accurate. In my testing, bash does not even perform this
canonicalization step, which is optional to begin with. That is, it
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
On Tue, 30 Jan 2024 10:34:28 -0500
Chet Ramey wrote:
> On 1/30/24 10:29 AM, Kerin Millar wrote:
>
> >>> I'm not sure that this is accurate. In my testing, bash does not even
> >>> perform this canonicalization step, which is optional to begin with. That
> >>> is, it states that "an
On Tue, 30 Jan 2024 10:13:37 -0500
Chet Ramey wrote:
> > POSIX Programmer's Manual (cd(1p) manpage) says this:
>
> I don't know what this is.
Some operating systems helpfully offer packages containing POSIX material in
the form of man pages. The pages covering the shell and standard utilities
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
On 1/30/24 10:29 AM, Kerin Millar wrote:
I'm not sure that this is accurate. In my testing, bash does not even perform this
canonicalization step, which is optional to begin with. That is, it states that "an
implementation may" canonicalize in the manner described, and prescribes a course of
On Jan 30 2024, Zachary Santer wrote:
> For that matter:
>
> $ echo \${var} # enter
> ${var}
> $ echo \${var} # M-C-e
> $ echo ${var} # enter
> foo
> # Would've expected: echo \${var}
>
> There's no way this is the intended behavior, right?
The command is doing exactly what it is documented to
On 1/28/24 9:36 AM, Kerin Millar wrote:
An associated issue is that there presently appears to be no way of suppressing
the processing of CDPATH in bash.
Only by using an absolute pathname. It's a non-optional part of the POSIX
algorithm.
--
``The lyf so short, the craft so long to lerne.''
On Tue, 30 Jan 2024 10:22:18 -0500
Chet Ramey wrote:
> On 1/28/24 10:34 AM, Kerin Millar wrote:
> > On Sun, 28 Jan 2024 18:09:24 +0300
> > Oğuz wrote:
> >
> >> On Sun, Jan 28, 2024 at 5:10 PM wrote:
> >>> POSIX Programmer's Manual (cd(1p) manpage) says this:
> >>>
> >>>[9 unrelated
On 1/28/24 10:34 AM, Kerin Millar wrote:
On Sun, 28 Jan 2024 18:09:24 +0300
Oğuz wrote:
On Sun, Jan 28, 2024 at 5:10 PM wrote:
POSIX Programmer's Manual (cd(1p) manpage) says this:
[9 unrelated special cases]
10. The cd utility shall then perform actions equivalent to the
> 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
On 1/27/24 10:30 PM, j...@jwo.cz wrote:
Hello,
(If you don't want to read through this stuff, see the end or grep for
word ``opinion''.)
I started exploring details of file handling on Linux and similar
systems and wondered what ``cd ""'' will do.
It's unspecified in the current POSIX
On Tue, Jan 30, 2024 at 9:11 AM Zachary Santer wrote:
> $ var='foo'
> $ echo "$( echo '${var}' )" # enter
> ${var}
> $ echo "$( echo '${var}' )" # M-C-e
> $ echo ${var} # enter
> foo
> # Would've expected: echo "\${var}"
> $ echo $( echo '${var}' ) # enter
> ${var}
> $ echo $( echo '${var}' ) #
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,
I think the results can be processed through methods such as `printf %q` or
`"${result@Q}"`
Replied Message
| From | Zachary Santer |
| Date | 01/30/2024 22:11 |
| To | A4-Tacks |
| Cc | bug-bash@gnu.org |
| Subject | Re: About `M-C-e` expand result `'` failed |
On Tue, Jan 30, 2024
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
On Tue, Jan 30, 2024 at 6:48 AM Zachary Santer wrote:
> Would it be unreasonable to expect that the argument to the outermost echo
> after M-C-e still be in double-quotes? Or potentially placed in
> single-quotes. That way, the line would be evaluated the same way as it
> would've been without
> > 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.
>
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
Even if this doesn't happen, you still don't end up with the command line
you probably wanted.
$ echo "$(echo $'ab\ncd\nef')" # enter
ab
cd
ef
$ echo "$(echo $'ab\ncd\nef')" # input M-C-e
$ echo ab
cd
ef # enter
ab
-bash: ef: command not found
And yes, that did change my working directory to my
25 matches
Mail list logo
