I have feature request: stack variable. Almost like current DIRSTACK
with 'pushd' and 'popd', but for regular arrays.
I know it can be implemented with array, where you push and pop from the
end. But, a real stack is better.
--
William Park
I agree: python seem to be more apropriated language for complex operation.
Anyway, bash already offer a lot of features (like `coproc` and `read -t 0`)
usefull for IPC.
I wrote a little ``multiping`` bash script, as multithread demo, running many
parallels ping, reading all outputs and merging t
On Sun, Dec 27, 2020 at 08:02:49AM -0500, Eli Schwartz wrote:
> I'm not sure I understand the question?
My interpretation is that for an async *simple* command of the
form cmd args & where cmd cannot be executed at all (due to
lack of permissions, perhaps, or because the external program is
no
On Mon, Dec 28, 2020 at 3:16 PM Greg Wooledge wrote:
> The problem is that the parent bash (the script) doesn't know, and
> cannot know, that the command was stillborn. Only the child bash
> process can know this, and by the time this information has become
> available, the parent bash process h
On 12/28/20 8:15 AM, Greg Wooledge wrote:
On Sun, Dec 27, 2020 at 08:02:49AM -0500, Eli Schwartz wrote:
I'm not sure I understand the question?
My interpretation is that for an async *simple* command of the
form cmd args & where cmd cannot be executed at all (due to
lack of permissions, pe
On 28/12/2020 at 21:18, Eli Schwartz wrote:
if cmd=$(type -P foo) && test -x "$foo"; then
foo &
else
echo "error: foo could not be found or is not executable"
fi
When you handle such logic within Bash you already lost on a race
condition when foo is readable and executable when you t
On 12/28/20 4:45 PM, Léa Gris wrote:
When you handle such logic within Bash you already lost on a race
condition when foo is readable and executable when you test it, but when
it reaches the actual execution, it is no longer the case.
Bash is full of race conditions, because bash was never mea
Markus Elfring writes:
> I imagine that it can be occasionally helpful to determine the execution
> failure
> in the synchronous way.
> Would it make sense to configure the error reporting for selected asynchronous
> commands so that they would become background processes only after the
> requir