Configuration Information [Automatically generated, do not change]:
Machine: aarch64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2
uname output: Linux nixos 6.1.77 #1-NixOS SMP Mon Feb 5 20:13:03 UTC 2024
aarch64 GNU/Linux
Machine Type: aarch64-unknown-linux-gnu
Bash Version: 5.2
Patch
On 7/31/24 11:48 AM, Zachary Santer wrote:
On Fri, Jul 26, 2024 at 10:19 AM Chet Ramey wrote:
You could have looked at the actual commit, which contains the change log,
which says
- wait_for_any_job: check for any terminated procsubs as well as any
terminated background jobs
wait_for_any
On 8/1/24 4:12 AM, Martin D Kealey wrote:
It follows that the following assertions are allowed to fail:
intptr_t i = 0;
assert(*(void*)i == (void*)0*);
void *p = 0;
assert(*(intptr_t)p == 0*);
Accordingly I provide the following patch:
I'm wondering why you chose these two cases
On 8/5/24 4:57 AM, Jae Juang wrote:
Bash Version: 5.2
Patch Level: 15
Release Status: release
Description:
In bash, the very useful shell-expand-line (`M-C-e`) expands command substitutions to
their contents, on the current line. However, this works very strangely for commands
without sheba
On Mon, Aug 5, 2024 at 9:54 AM Chet Ramey wrote:
>
> On 7/31/24 11:48 AM, Zachary Santer wrote:
> >
> > $ wait -n > >( cat )
> > would hang, in the event that there are no other un-waited-for child
> > processes, right?
>
> Yes, it will wait for the next job or procsub to terminate.
Basically the
Thank you! Indeed a build from branch bash-5.3-testing shows the issue to be
fixed (devel did not build for me). I look forward to the release of the fix.
On Tue, Aug 6, 2024, at 1:41 AM, Chet Ramey wrote:
> On 8/5/24 4:57 AM, Jae Juang wrote:
>
> > Bash Version: 5.2
> > Patch Level: 15
> > Rele
On 8/5/24 2:21 PM, Zachary Santer wrote:
On Mon, Aug 5, 2024 at 9:54 AM Chet Ramey wrote:
On 7/31/24 11:48 AM, Zachary Santer wrote:
$ wait -n > >( cat )
would hang, in the event that there are no other un-waited-for child
processes, right?
Yes, it will wait for the next job or procsub to
On Mon, Aug 5, 2024 at 5:10 PM Chet Ramey wrote:
>
> But in the end, if you're waiting for a process that isn't going to
> terminate, you're going to be waiting for a long time.
So, even with wait without id arguments restricted to the final
procsub, if its process id is the same as $!, it's stil
On Tuesday, August 6, 2024, Zachary Santer wrote:
> I
> don't see the benefit over simply waiting for all process
> substitutions.
>
The benefit is they're separate from async jobs and don't get in your way.
`wait' waiting for the last procsub is acceptable, `wait' waiting for a
procsub that I f
imo have multiple $! at once set is to me a hard must , when more are
invoked .. this is a programmical must .. or do only i see these schematics
.. a no is brainless ..
.. in the way not supporting floating math .. so i should not care so much
=pp =)
On Tue, Aug 6, 2024, 07:19 Oğuz wrote:
> On
10 matches
Mail list logo
