bug-bash
[Top][All Lists]
Advanced

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

Re: slow bgp_delete


From: Vladimir Marek
Subject: Re: slow bgp_delete
Date: Tue, 23 Jun 2015 17:11:34 +0200
User-agent: Mutt/1.5.22.1-rc1 (2013-10-16)

> > 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.

Thank you, that corresponds with my thoughts.

-- 
        Vlad



reply via email to

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