bug-bash
[Top][All Lists]
Advanced

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

Re: slow bgp_delete


From: Chet Ramey
Subject: Re: slow bgp_delete
Date: Tue, 23 Jun 2015 10:47:31 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

On 6/23/15 5:13 AM, Vladimir Marek wrote:

> The patch works nicely. However there were internal concerns that this
> change might cause some incompatibility to existing scripts. I would
> like to ask for your opinion on it.
> 
> I am trying to come up with a scenario where this change might cause
> existing script to break. This would be one possibility:
> 
> PID=$( echo $BASHPID; exec synchronous_command )
> wait $PID
> RET=$?
> 
> Before the patch in question this would return the exit status of
> 'synchronous_command', afther the change one would get error
> 
> bash: wait: pid 1234 is not a child of this shell
> 
> 
> There might be other ways of passing the PID value out of the subshell,
> but otherwise it's pretty much I can think of.
> 
> I would say that it is very unlikely someone would be running such a
> construct (especially it is not explicitly mentioned in the man page
> that synchronous jobs are being captured). But you will probably have
> better idea how bash is (ab)used; how serious do you think this is?

I don't think it's a serious problem at all.  The `wait' is not necessary
to get the status of the command substitution, as long as you reference $?
immediately after the command substitution completes -- the status of an
assignment statement is the status of any command substitutions it contains.

Since there's an easy workaround for what I suspect is a rarely-used idiom,
and there's no reason to use `wait' for a synchronous command, I don't
anticipate any problems with the change.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    address@hidden    http://cnswww.cns.cwru.edu/~chet/



reply via email to

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