On May 28, 2013, at 8:07 AM, Reid Linnemann wrote:
>
> On May 28, 2013, at 7:00 AM, Ryan Stone <ryst...@gmail.com> wrote:
>
>> On Tue, May 28, 2013 at 5:48 AM, Václav Zeman <vhais...@gmail.com> wrote:
>> Curious. Which of the two behaviours is POSIXly correct?
>>
>> I believe that /bin/sh's behaviour is correct. I don't know what shell the
>> manpage is referring to, but it's not bash (bash does the same thing in a
>> pipeline). Perhaps it's referring to csh? If that is the case that line is
>> probably causing more confusion rather than alleviating it.
>
> I believe it's referring to csh, possible ksh as well. I tried a similar
> experiment with tcsh:
>
> #!/bin/tcsh
> alias fn set var=12
> set var=
> echo $var
> yes | fn
> echo $var
I wonder why the sh(1) manual would be referring to csh(1).
CSH does more than this, so you know…
#!/bin/csh
true | true | false | true
# returns false
#!/bin/sh
true | true | false | true
# returns true
So not only must you be aware that sh(1) throws away variables assigned within
a shell running as an rvalue to any pipe (because said statements are run in a
sub-shell with a transient namespace initialized from the parent)…
You must also be aware that return status of an lvalue operand of a pipe is not
retained along the chain. The entire chain is traversed (all rvalues of all
pipes are invoked), but in sh(1) only the return status of last rvalue is
returned.
I see this problem running rampant in the pc-sysinstall code.
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
NOTE: I'm responding on another thread that is related to pc-sysinstall
changes. In that thread, I didn't mention the above faux-pas of pc-sysinstall
because I really do consider things like this to be secondary to the
over-arching namespace and debugging issues.
_____________
The information contained in this message is proprietary and/or confidential.
If you are not the intended recipient, please: (i) delete the message and all
copies; (ii) do not disclose, distribute or use the message in any manner; and
(iii) notify the sender immediately. In addition, please be aware that any
message addressed to our domain is subject to archiving and review by persons
other than the intended recipient. Thank you.
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
