Redirections > and >> don't put it in a subshell.
Only pipe |, which means only STDIN affects/triggers this behaviour.
Does < operator also does it, as it is also STDIN?
Anyway, I don't care for executing binaries, but I do care if that is part of
sh's code, as function is.
It messes var scopes.
And finally if we take into account this:
> For example… in pc-sysinstall…
>
> ./backend/functions-extractimage.sh- tar cvf - . 2>/dev/null | tar -xpv
> -C ${FSMNT} ${TAROPTS} -f - 2>&1 | tee -a ${FSMNT}/.tar-extract.log
> ./backend/functions-extractimage.sh: if [ $? -ne 0 ]
>
> That's a big no-no.
>
> If your first tar (the initial lvalue to the first pipe) fails… but your
> second tar succeeds (rvalue to the first pipe)… you won't catch that failure
> in your checking of $?
>
> Also, if the first tar succeeds, but the second tar fails, AND the final
> rvalue (the tee) succeeds… you also miss the error code.
>
> I call this the "piped return-status conflation issue". Basically… anytime
> you want to check the return-status in shell… and you care about
> lvalue-failures in a pipe-chain… you must rewrite it to either:
>
> (a) be aware of the problem (I've in the past written wrappers that will test
> the previous return status and abort the chain in such an event)
>
> (b) undo the pipe-chain and store your results for incremental processing…
> checking the return status after each filter.
>
> --
> Devin
sh's behaviour must be changed regarding pipeing
> > Curious. Which of the two behaviours is POSIXly correct?
>
> Both. As per XCU 2.12 Shell Execution Environment, each command in a
> multi-command pipeline may or may not be executed in a subshell
> environment.
>
> Behaviour different from our sh is most often encountered in the various
> versions of the real Korn shell (ksh88 and ksh93), which execute the
> last command in a pipeline in the current shell environment.
>
> If things like jobs | cat work, that can also be explained using this
> rule.
>
> --
> Jilles Tjoelker
>
Domagoj Smolčić
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[email protected]"
