[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 chet@case.edu http://cnswww.cns.cwru.edu/~chet/