Date:Tue, 29 Dec 2020 10:23:07 -0500
From:Chet Ramey
Message-ID:
| Bash will save some number of exit statuses corresponding to terminated
| asynchronous child processes, and those statuses are retrievable using
| `wait'. That number varies -- POSIX says you ne
On 12/29/20 10:28 AM, Chet Ramey wrote:
On 12/28/20 5:30 PM, Eli Schwartz wrote:
(Though I have to wonder at these amazing AWOL commands that get
uninstalled on people all the time right in the middle of their scripts.
It's a potential security concern, though that class of vulnerabilities
m
On 12/28/20 5:30 PM, Eli Schwartz wrote:
(Though I have to wonder at these amazing AWOL commands that get
uninstalled on people all the time right in the middle of their scripts.
It's a potential security concern, though that class of vulnerabilities
mostly involves executables being changed
On 12/28/20 1:23 AM, Markus Elfring wrote:
I got another programming concern:
Process identifications are a system resource.
The exit status is preserved until this information will eventually be used
for corresponding data processing.
How many processes can a selected system configuration handl
>…, is not a winning argument.
I got further development ideas according to the usage of wait function calls
and better error reporting for asynchronous commands.
>The OP seems to think that "people will occasionally forget to run `wait`",
This happens for various reasons.
> and wants to know
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
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
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 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 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 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
>> Would you care if waiting on such identifications for background processes
>> will occasionally be forgotten?
>>
>> How many efforts would you invest to add potentially missing wait function
>> calls?
>
> It's axiomatic: if you want to make a decision based on the exit status of
> any asynchron
On 12/27/20 5:01 AM, Markus Elfring wrote:
If you have the pid of an asynchronous command -- and the easiest way to get
that pid
is by referencing $! after it was started -- you can call `wait' with that pid
to retrieve the status, even if it's already terminated.
Would you care if waiting on
On 12/27/20 5:01 AM, Markus Elfring wrote:
If you have the pid of an asynchronous command -- and the easiest way to get
that pid
is by referencing $! after it was started -- you can call `wait' with that pid
to retrieve the status, even if it's already terminated.
Would you care if waiting on
> If you have the pid of an asynchronous command -- and the easiest way to get
> that pid
> is by referencing $! after it was started -- you can call `wait' with that pid
> to retrieve the status, even if it's already terminated.
Would you care if waiting on such identifications for background pr
On 12/26/20 4:10 AM, Markus Elfring wrote:
If you want the exit status of the child process, add `wait $!'
Thanks for this information.
Is there a need then to point the aspect out that exit values can be determined
for child processes even if they terminated before a wait command would be
pe
> If you want the exit status of the child process, add `wait $!'
Thanks for this information.
Is there a need then to point the aspect out that exit values can be determined
for child processes even if they terminated before a wait command would be
performed?
Regards,
Markus
On 12/25/20 4:40 AM, Markus Elfring wrote:
Hello,
I am looking for another bit of clarification according to an implementation
detail.
The manual is providing the following information.
https://git.savannah.gnu.org/cgit/bash.git/tree/doc/bash.1?id=76404c85d492c001f59f2644074333ffb7608532#n627
> Are you maybe saying
>
> cmd &
>
> should be a special case?
I got special imaginations according to such a command variant.
Regards,
Markus
On Fri, Dec 25, 2020 at 10:40:17AM +0100, Markus Elfring wrote:
> Hello,
>
> I am looking for another bit of clarification according to an implementation
> detail.
>
> The manual is providing the following information.
> https://git.savannah.gnu.org/cgit/bash.git/tree/doc/bash.1?id=76404c85d492c
Hello,
I am looking for another bit of clarification according to an implementation
detail.
The manual is providing the following information.
https://git.savannah.gnu.org/cgit/bash.git/tree/doc/bash.1?id=76404c85d492c001f59f2644074333ffb7608532#n627
“…
If a command is terminated by the
21 matches
Mail list logo
