Date: Tue, 28 May 2013 17:28:47 +0000 From: "Teske, Devin" <Devin.Teske@fisglobal.com> To: Reid Linnemann <linnemannr@gmail.com> Cc: "rank1seeker@gmail.com" <rank1seeker@gmail.com>, Devin Teske <dteske@freebsd.org>, FreeBSD Hackers <hackers@freebsd.org>, Ryan Stone <rysto32@gmail.com> Subject: Re: /bin/sh => STDIN & functions, var scope messing Message-ID: <13CA24D6AB415D428143D44749F57D7201F64904@ltcfiswmsgmb21> In-Reply-To: <47252E1F-0965-4772-AE40-865BE5D05CD8@gmail.com> References: <20130527.194235.693.1@DOMY-PC> <CA%2B0MdpOcz7aw03HCrbxZVt1cnWdR4shqWaEfBrQkCpPnbgXLPQ@mail.gmail.com> <CAKw7uVjty2cJXT_QmexxKdRQyiKoHYMK1E-TjSHa5TCX1S8Bbg@mail.gmail.com> <CAFMmRNz8p4t=PEstsy5itKYPUiJzo5_48L9sJWQxWjWrXcpDmg@mail.gmail.com> <47252E1F-0965-4772-AE40-865BE5D05CD8@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 28, 2013, at 8:07 AM, Reid Linnemann wrote:
>=20
> On May 28, 2013, at 7:00 AM, Ryan Stone <rysto32@gmail.com> wrote:
>=20
>> On Tue, May 28, 2013 at 5:48 AM, V=E1clav Zeman <vhaisman@gmail.com> wro=
te:
>> Curious. Which of the two behaviours is POSIXly correct?
>>=20
>> 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 lin=
e is probably causing more confusion rather than alleviating it.
>=20
> I believe it's referring to csh, possible ksh as well. I tried a similar =
experiment with tcsh:
>=20
> #!/bin/tcsh
> alias fn set var=3D12
> set var=3D
> 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=85
#!/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 wit=
hin a shell running as an rvalue to any pipe (because said statements are r=
un in a sub-shell with a transient namespace initialized from the parent)=85
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 o=
f all pipes are invoked), but in sh(1) only the return status of last rvalu=
e is returned.
I see this problem running rampant in the pc-sysinstall code.
For example=85 in pc-sysinstall=85
./backend/functions-extractimage.sh- tar cvf - . 2>/dev/null | tar -xp=
v -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=85 but your =
second tar succeeds (rvalue to the first pipe)=85 you won't catch that fail=
ure in your checking of $?
Also, if the first tar succeeds, but the second tar fails, AND the final rv=
alue (the tee) succeeds=85 you also miss the error code.
I call this the "piped return-status conflation issue". Basically=85 anytim=
e you want to check the return-status in shell=85 and you care about lvalue=
-failures in a pipe-chain=85 you must rewrite it to either:
(a) be aware of the problem (I've in the past written wrappers that will te=
st the previous return status and abort the chain in such an event)
(b) undo the pipe-chain and store your results for incremental processing=
=85 checking the return status after each filter.
--=20
Devin
NOTE: I'm responding on another thread that is related to pc-sysinstall cha=
nges. 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-a=
rching namespace and debugging issues.
_____________
The information contained in this message is proprietary and/or confidentia=
l. If you are not the intended recipient, please: (i) delete the message an=
d all copies; (ii) do not disclose, distribute or use the message in any ma=
nner; and (iii) notify the sender immediately. In addition, please be aware=
that any message addressed to our domain is subject to archiving and revie=
w by persons other than the intended recipient. Thank you.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?13CA24D6AB415D428143D44749F57D7201F64904>