On Sat, Oct 12, 2024 at 12:33 PM Oğuz wrote:
>
> On Saturday, October 12, 2024, Zachary Santer wrote:
>>
>> Backwards compatibility with people's expectations
>
> No one expects children of the same parent to be able to wait for eachother.
> It's common sense.
$ ( set -x; : & wait -- "${sibling
On Saturday, October 12, 2024, Zachary Santer wrote:
>
> Backwards compatibility with people's expectations
No one expects children of the same parent to be able to wait for
eachother. It's common sense.
--
Oğuz
On Sun, Jul 14, 2024 at 8:40 PM Zachary Santer wrote:
>
> On Tue, Jul 9, 2024 at 2:37 PM Zachary Santer wrote:
> >
> > On the other hand, do funsubs give us the answer here?
> >
> > shopt -s lastpipe
> > declare -a pid=()
> > command-1 | tee >( command-2 ) ${ pid+=( "${!}" ); } >( command-3 ) ${
On Wed, Aug 7, 2024 at 10:27 AM Chet Ramey wrote:
>
> On 8/5/24 11:00 PM, Zachary Santer wrote:
> > 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
On 8/5/24 11:00 PM, Zachary Santer wrote:
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 it
On Tue, Aug 6, 2024 at 3:20 PM Oğuz wrote:
>
> To me it just shows how lost you are, sorry. Perhaps you should consider
> other languages, or write a utility that makes setting up FIFOs easier, I
> don't know.
All the scripts I've discussed in this email list run and act on the
output of extern
On Tuesday, August 6, 2024, Zachary Santer wrote:
>
> This I guess makes a further point about the need to anticipate what
> shell programmers might want or need to be able to do.
To me it just shows how lost you are, sorry. Perhaps you should consider
other languages, or write a utility that ma
On Tue, Aug 6, 2024 at 10:21 AM Oğuz wrote:
>
> On Tuesday, August 6, 2024, Zachary Santer wrote:
>>
>> How bash is actually used should guide its development.
>
> Correct. No one waits for procsubs in their scripts or on the command line.
On Wed, Jul 3, 2024 at 8:40 PM Zachary Santer wrote:
>
On Tuesday, August 6, 2024, Zachary Santer wrote:
>
> How bash is actually used should guide its development.
Correct. No one waits for procsubs in their scripts or on the command line.
In a script, a child process being a job or not makes no difference,
> from the shell programmer's perspectiv
On Tue, Aug 6, 2024 at 9:09 AM Oğuz wrote:
>
> On Tue, Aug 6, 2024 at 2:58 PM Zachary Santer wrote:
> > I can not think of a time when I called 'wait' from the command line
> > that wasn't just for testing something. Even using process
> > substitutions on the command line is a relative rarity fo
On Tue, Aug 6, 2024 at 2:58 PM Zachary Santer wrote:
> I can not think of a time when I called 'wait' from the command line
> that wasn't just for testing something. Even using process
> substitutions on the command line is a relative rarity for me. If
> we're balancing behavior on the command lin
On Tue, Aug 6, 2024, 13:59 Zachary Santer wrote:
> On Tue, Aug 6, 2024 at 1:19 AM Oğuz wrote:
> >
> > 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 forgot about and that won't
On Tue, Aug 6, 2024 at 1:19 AM Oğuz wrote:
>
> 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 forgot about and that won't be listed by `jobs' is not.
I can not think of a time
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
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
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 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 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
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 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_job is the function that backs `w
On 7/20/24 10:47 AM, Zachary Santer wrote:
I feel like that's most of the way there. I would argue 'wait -n'
without arguments should include the "last-executed process
substitution, if its process id is the same as $!," in the set of
running child processes it'll wait for, at least. Just for th
On Thu, Jul 18, 2024 at 5:02 PM Chet Ramey wrote:
>
> It's not in the set of changes to `wait -n' I just pushed, but it will be
> in the next push.
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: msys
Compiler: gcc
Compilation CFLAGS: -g -O2
uname output: M
On 7/14/24 8:40 PM, Zachary Santer wrote:
See my attachments, though. Something about my second set of process
substitutions is causing 'wait' without arguments to not wait for the
final procsub, whose pid is still in $! at the time.
There's an easy fix for this, thanks.
It's not in the set o
On 7/14/24 8:40 PM, Zachary Santer wrote:
On Fri, Jul 5, 2024 at 2:38 PM Chet Ramey wrote:
There is code tagged
for bash-5.4 that allows `wait -n' to look at these exited processes as
long as it's given an explicit set of pid arguments.
I agree with all the knowledgeable people here telling
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: msys
Compiler: gcc
Compilation CFLAGS: -g -O2
uname output: MSYS_NT-10.0-19045 Zack2021HPPavilion
3.5.3-d8b21b8c.x86_64 2024-07-09 18:03 UTC x86_64 Msys
Machine Type: x86_64-pc-msys
Bash Version: 5.3
Patch Leve
On Saturday, July 13, 2024, Greg Wooledge wrote:
>
> If two jobs happen to finish simultaneously, the next call to wait -n
> should reap one of them, and then the call after that should reap
> the other. That's how everyone wants it to work, as far as I've seen.
>
> *Nobody* wants it to skip the
On Sat, Jul 13, 2024 at 07:40:42 +0700, Robert Elz wrote:
> Please just change this, use the first definition of "next job to
> finish" - and in the case when there are already several of them,
> pick one, any one - you could order them by the time that bash reaped
> the jobs internally, but there'
Date:Fri, 12 Jul 2024 11:48:15 -0400
From:Chet Ramey
Message-ID: <258bcd3a-a936-4751-8e24-916fbeb9c...@case.edu>
| Not really, since the original intent was to wait for the *next* process
| to terminate.
There are two issues with that. The first is "next after
On 7/9/24 6:12 AM, Zachary Santer wrote:
On Fri, Jul 5, 2024 at 2:38 PM Chet Ramey wrote:
On 6/29/24 10:51 PM, Zachary Santer wrote:
so you were then able to wait for each process substitution individually,
as long as you saved $! after they were created. `wait' without arguments
would still
On Tue, Jul 9, 2024 at 6:12 AM Zachary Santer wrote:
>
> command-1 | tee >( command-2 ) >( command-3 ) >( command-4 )
> wait
>
> The workaround for this not working would of course be named pipes,
> which is somewhat less trivial.
> Bash is already tracking the pids for all child processes not wa
On Fri, Jul 5, 2024 at 2:38 PM Chet Ramey wrote:
>
> On 6/29/24 10:51 PM, Zachary Santer wrote:
>
> so you were then able to wait for each process substitution individually,
> as long as you saved $! after they were created. `wait' without arguments
> would still wait for all process substitutions
On Mon, Jul 8, 2024, 22:57 Greg Wooledge wrote:
> On Mon, Jul 08, 2024 at 22:45:35 +0200, alex xmb sw ratchev wrote:
> > On Mon, Jul 8, 2024, 22:15 Chet Ramey wrote:
> >
> > > On 7/8/24 4:02 PM, alex xmb sw ratchev wrote:
> > >
> > > > hi , one question about ..
> > > > if a cmd contains more su
On Mon, Jul 08, 2024 at 22:45:35 +0200, alex xmb sw ratchev wrote:
> On Mon, Jul 8, 2024, 22:15 Chet Ramey wrote:
>
> > On 7/8/24 4:02 PM, alex xmb sw ratchev wrote:
> >
> > > hi , one question about ..
> > > if a cmd contains more substitions like >( or <( , how to get all $!
> > > maybe make ${
On Mon, Jul 8, 2024, 22:15 Chet Ramey wrote:
> On 7/8/24 4:02 PM, alex xmb sw ratchev wrote:
>
> > hi , one question about ..
> > if a cmd contains more substitions like >( or <( , how to get all $!
> > maybe make ${![]} , or is such already .. ?
>
> You can't. Process substitutions set $!, but y
On 7/8/24 4:02 PM, alex xmb sw ratchev wrote:
hi , one question about ..
if a cmd contains more substitions like >( or <( , how to get all $!
maybe make ${![]} , or is such already .. ?
You can't. Process substitutions set $!, but you have to have a point
where you can capture that if you want
On Mon, Jul 8, 2024, 21:55 Chet Ramey wrote:
> On 7/8/24 3:27 PM, Dale R. Worley wrote:
> > Greg Wooledge writes:
> >> Some scripts use something like this:
> >> ...
> >> exec > >(command ...) ...
> >
> > I've used that construction quite a few times myself. I'm not
> > requesting that the
On 7/8/24 3:27 PM, Dale R. Worley wrote:
Greg Wooledge writes:
Some scripts use something like this:
...
exec > >(command ...) ...
I've used that construction quite a few times myself. I'm not
requesting that the resulting process be waitable, but certainly
whatever the maintainers desi
Greg Wooledge writes:
> Some scripts use something like this:
> ...
> exec > >(command ...) ...
I've used that construction quite a few times myself. I'm not
requesting that the resulting process be waitable, but certainly
whatever the maintainers design should take into account that this is
On Fri, Jul 05, 2024 at 15:16:31 -0400, Chet Ramey wrote:
> They're similar, but they're not jobs. They run in the background, but you
> can't use the same set of job control primitives to manipulate them.
> Their scope is expected to be the lifetime of the command they're a part
> of, not run in t
On 7/3/24 8:40 PM, Zachary Santer wrote:
On Wed, Jul 3, 2024 at 11:21 AM Chet Ramey wrote:
Process substitutions are word expansions, with a scope of a single
command, and are not expected to survive their read/write file descriptors
becoming invalid. You shouldn't need to `wait' for them; the
On 7/2/24 9:59 PM, Zachary Santer wrote:
I *am* seeing a difference between having lastpipe enabled (and job
control off) or not when running your example in the interactive
shell, though:
SECONDS=0; echo $'foo\nbar' | tee >(echo first ; exit 1) >(wc ; sleep
10 ; echo wc) >(tail -n 1; echo tail)
On 6/29/24 10:51 PM, Zachary Santer wrote:
They might already. Now I'm wondering if the documentation just needed updating.
It might, but maybe not how you think. See below.
I'm afraid to report this as a bug, because it feels like something
that running bash in MSYS2 on Windows could be re
Reading this discussion, I notice a subtlety. If you execute:
$ command-A >( command-1) <( command-2 )
$ command-B
when command-B executes, command-2 must have terminated already because
command-A wouldn't have seen the EOF from command-2 until command-2
terminated. (OK, I am assuming here that
On Wed, Jul 3, 2024 at 11:21 AM Chet Ramey wrote:
>
> Process substitutions are word expansions, with a scope of a single
> command, and are not expected to survive their read/write file descriptors
> becoming invalid. You shouldn't need to `wait' for them; they're not
> true asynchronous processe
On Thu, 4 Jul 2024, 03:21 Chet Ramey, wrote:
> Why not just wait for all process substitutions?
> Process substitutions [...] are not expected to survive their read/write
> file descriptors becoming invalid. You shouldn't need to `wait' for them;
> they're not true asynchronous processes.
>
A
On 6/29/24 8:47 AM, Zachary Santer wrote:
From the manual:
wait [-fn] [-p varname] [id ...]
Wait for each specified child process and return its termination
status. Each id may be a process ID or a job specification; if a job
spec is given, all processes in that job's pipeline are waited for. If
On Tue, Jul 2, 2024 at 9:59 PM Zachary Santer wrote:
>
> I *am* seeing a difference between having lastpipe enabled (and job
> control off) or not when running your example in the interactive
> shell, though:
> SECONDS=0; echo $'foo\nbar' | tee >(echo first ; exit 1) >(wc ; sleep
> 10 ; echo wc) >
On Tue, Jul 2, 2024 at 4:56 PM Mark March wrote:
>
> lastpipe takes effect only if job control is off. From the man page:
>
> lastpipe
> If set, and job control is not active, the shell
>
> With laspipe on and job control off, 'wait' appears to wait for all process
lastpipe takes effect only if job control is off. From the man page:
lastpipe
If set, and job control is not active, the shell
With laspipe on and job control off, 'wait' appears to wait for all process
substitutions:
set +mshopt -s lastpipe
echo $'foo\nbar' | tee
On Sun, 30 Jun 2024 at 05:08, Zachary Santer wrote:
> On the other hand, I'm pretty sure
> command-1 | tee >( command-2 ) >( command-3 ) >( command-4 )
> will terminate as soon as command-1 and tee have terminated, but the
> command substitutions could still be running. If you want to run
> comma
On Sat, Jun 29, 2024 at 2:07 PM Oğuz wrote:
>
> There is a limit to the number of jobs Bash can remember, once it's exceeded
> the oldest job is overwritten. Do we really want process substitutions to
> count against that limit?
They might already. Now I'm wondering if the documentation just ne
On Sat, Jun 29, 2024 at 8:08 PM Zachary Santer wrote:
> Is that relevant?
I think so. There is a limit to the number of jobs Bash can remember, once
it's exceeded the oldest job is overwritten. Do we really want process
substitutions to count against that limit? Or did you mean something else?
-
On Sat, Jun 29, 2024 at 11:30 AM Oğuz wrote:
>
> On Saturday, June 29, 2024, Zachary Santer wrote:
>>
>> Couldn't you do the exact same thing with regular background processes
>> forked with &?
>
>
> But the shell notifies me when they terminate and reap them.
Is that relevant?
$ { sleep 5; pri
On Saturday, June 29, 2024, Zachary Santer wrote:
>
> Couldn't you do the exact same thing with regular background processes
> forked with &?
>
But the shell notifies me when they terminate and reap them.
--
Oğuz
On Sat, Jun 29, 2024 at 9:02 AM Oğuz wrote:
>
> What if I substitute thousands of processes and never call wait?
Couldn't you do the exact same thing with regular background processes
forked with &? That's on you.
On Sat, Jun 29, 2024 at 3:47 PM Zachary Santer wrote:
> Why not just wait for all process substitutions?
What if I substitute thousands of processes and never call wait?
>From the manual:
wait [-fn] [-p varname] [id ...]
Wait for each specified child process and return its termination
status. Each id may be a process ID or a job specification; if a job
spec is given, all processes in that job's pipeline are waited for. If
id is not given, wait waits for all running
57 matches
Mail list logo
