/bin/sh => STDIN & functions, var scope messing

[Teske, Devin]

On May 31, 2013, at 10:59 AM, <rank1seeker at gmail.com>
 wrote:

> Redirections > and >> don't put it in a subshell.

Correct. (note: I made no such insinuation; But thanks for clarifying for others that perhaps were not aware).


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

If you're arguing we have to change sh's behavior to be more compliant, jilles already quoted XCU 2.12 (our shell is well within its right to run any/all lvalue/rvalue operands of a pipe in a sub-shell without contradicting the guidelines).

But if you're arguing that it has to change to make things better or easier… I don't know about that. Might just make people lulled into using a style that's non-portable. I'd like to keep things the way they are so that if you program for FreeBSD, you're inherently going to program in a fashion that is more portable.
-- 
Devin




>>> 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ć
> 
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"

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