Unexpected behaviour when using process substitution with stdout and stderr

2021-07-11 Thread earnestly
GNU bash, version 5.1.8(1)-release (x86_64-pc-linux-gnu) I have attempted to use process substitution in order to feed the output of a command into two filters, one for handling stdout and the other for stderr. Prior to this I was using POSIX sh and named pipes to achieve this but decided to try

Re: PROMPT_COMMAND is not executed after edit-and-execute-command

2021-03-18 Thread earnestly
On Thu, Mar 18, 2021 at 03:49:33PM -0400, Chet Ramey wrote: > Since readline prints the prompt as part of redisplay, and it doesn't know > anything about PROMPT_COMMAND or command execution, it doesn't execute it. That makes sense but doesn't bode well for my issue. Perhaps I can find a way to ex

PROMPT_COMMAND is not executed after edit-and-execute-command

2021-03-18 Thread earnestly
When using edit-and-execute-command to edit the command-line I've noticed that PROMPT_COMMAND is not evaluated upon returning to the prompt, e.g.: earnest i ~ PROMPT_COMMAND='echo foobar' foobar earnest i ~ set -x ++ echo foobar foobar earnest c ~ # use edit-and-execute-com

Re: How does this wait -n work to cap parallelism?

2019-07-29 Thread Earnestly
On Mon, Jul 29, 2019 at 07:12:42PM +0100, Earnestly wrote: > The question is about how the example works in order to maintain > parallelism capped at num_proc. Thanks to emg on #bash for explaining how what is essentially going on. Bash essentially maintains a list of completed jobs until w

Re: How does this wait -n work to cap parallelism?

2019-07-29 Thread Earnestly
On Mon, Jul 29, 2019 at 02:38:48PM -0400, Greg Wooledge wrote: > The same happens for my_job 7, and my_job 8. Each one is preceded by > a wait -n, so it waits for one of the existing jobs to terminate before > the new job is launched. This aspect of the behaviour isn't in question. Without reite

How does this wait -n work to cap parallelism?

2019-07-29 Thread Earnestly
This mail was spurred on by users in the #bash IRC channel. It started after reading where the article introduces an example using 'wait -n' as a means to provide capped parallism: #!/usr/bin/env bash # number of processes to run in