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