Date: Fri, 31 May 2013 18:12:03 +0000 From: "Teske, Devin" <Devin.Teske@fisglobal.com> To: "<rank1seeker@gmail.com> " <rank1seeker@gmail.com> Cc: Devin Teske <dteske@freebsd.org>, FreeBSD Hackers <hackers@freebsd.org>, Jilles Tjoelker <jilles@stack.nl> Subject: Re: /bin/sh => STDIN & functions, var scope messing Message-ID: <13CA24D6AB415D428143D44749F57D7201F6AD11@ltcfiswmsgmb21> In-Reply-To: <20130531.175959.745.2@DOMY-PC> References: <20130527.194235.693.1@DOMY-PC> <CA%2B0MdpOcz7aw03HCrbxZVt1cnWdR4shqWaEfBrQkCpPnbgXLPQ@mail.gmail.com> <CAKw7uVjty2cJXT_QmexxKdRQyiKoHYMK1E-TjSHa5TCX1S8Bbg@mail.gmail.com> <20130530223031.GA1672@stack.nl> <20130531.175959.745.2@DOMY-PC>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 31, 2013, at 10:59 AM, <rank1seeker@gmail.com>
wrote:
> Redirections > and >> don't put it in a subshell.
Correct. (note: I made no such insinuation; But thanks for clarifying for o=
thers 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?
>=20
> Anyway, I don't care for executing binaries, but I do care if that is par=
t of sh's code, as function is.
> It messes var scopes.
>=20
> And finally if we take into account this:
>=20
>> For example=85 in pc-sysinstall=85
>>=20
>> ./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 ]
>>=20
>> That's a big no-no.
>>=20
>> If your first tar (the initial lvalue to the first pipe) fails=85 but yo=
ur second tar succeeds (rvalue to the first pipe)=85 you won't catch that f=
ailure in your checking of $?
>>=20
>> Also, if the first tar succeeds, but the second tar fails, AND the final=
rvalue (the tee) succeeds=85 you also miss the error code.
>>=20
>> I call this the "piped return-status conflation issue". Basically=85 any=
time you want to check the return-status in shell=85 and you care about lva=
lue-failures in a pipe-chain=85 you must rewrite it to either:
>>=20
>> (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)
>>=20
>> (b) undo the pipe-chain and store your results for incremental processin=
g=85 checking the return status after each filter.
>>=20
>> --=20
>> Devin
>=20
>=20
> sh's behaviour must be changed regarding piping
>=20
If you're arguing we have to change sh's behavior to be more compliant, jil=
les 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 t=
he guidelines).
But if you're arguing that it has to change to make things better or easier=
=85 I don't know about that. Might just make people lulled into using a sty=
le 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 t=
hat is more portable.
--=20
Devin
>>> Curious. Which of the two behaviours is POSIXly correct?
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> If things like jobs | cat work, that can also be explained using this
>> rule.
>>=20
>> --=20
>> Jilles Tjoelker
>>=20
>=20
>=20
> Domagoj Smol=E8i=E6
>=20
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
_____________
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?13CA24D6AB415D428143D44749F57D7201F6AD11>