[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Checking executability for asynchronous commands

From: Eli Schwartz
Subject: Re: Checking executability for asynchronous commands
Date: Mon, 28 Dec 2020 15:18:01 -0500

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, perhaps, or because the external program is
not installed), they want bash to set $? to a nonzero value to
indicate that the command couldn't even be started.

I've seen similar requests several times over the years.

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 has already moved on.

The only way the parent can obtain this information is to wait until
that information becomes available.

Actually, I don't see why one could not circumvent the entire process, and do this instead

if cmd=$(type -P foo) && test -x "$foo"; then
    foo &
    echo "error: foo could not be found or is not executable"

But I do get the initial premise of the thread. I don't get the *defense* being offered though. The logic here seems to be completely bankrupt -- saying bash needs new features (that are not well thought out) so you don't "need" to include code to handle your intentions, is not a winning argument.

The OP seems to think that "people will occasionally forget to run `wait`", and wants to know if we "care" that people will forget and if Chet will add new features to bash in order to cater to these forgetful people. This is what I don't understand. Why should we care? The official advice is to run `wait` (or perform executability checks upfront, or whatever).

Eli Schwartz
Arch Linux Bug Wrangler and Trusted User

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]