From owner-freebsd-hackers@FreeBSD.ORG Tue May 28 17:28:49 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A9E08C0C; Tue, 28 May 2013 17:28:49 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 761CAA36; Tue, 28 May 2013 17:28:48 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa01.fnfis.com (8.14.5/8.14.5) with ESMTP id r4SHSlwa027766 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 28 May 2013 12:28:47 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([10.132.99.23]) by LTCFISWMSGHT04.FNFIS.com ([10.132.206.15]) with mapi id 14.02.0309.002; Tue, 28 May 2013 12:28:47 -0500 From: "Teske, Devin" To: Reid Linnemann Subject: Re: /bin/sh => STDIN & functions, var scope messing Thread-Topic: /bin/sh => STDIN & functions, var scope messing Thread-Index: AQHOWxJjvvyJSeBFUUSS2KYxPIq87pkZxr8AgADoBoCAACTsAIAANEIAgAAnVwA= Date: Tue, 28 May 2013 17:28:47 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201F64904@ltcfiswmsgmb21> References: <20130527.194235.693.1@DOMY-PC> <47252E1F-0965-4772-AE40-865BE5D05CD8@gmail.com> In-Reply-To: <47252E1F-0965-4772-AE40-865BE5D05CD8@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.126] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-05-28_08:2013-05-28,2013-05-28,1970-01-01 signatures=0 Cc: "rank1seeker@gmail.com" , Devin Teske , FreeBSD Hackers , Ryan Stone X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 17:28:49 -0000 On May 28, 2013, at 8:07 AM, Reid Linnemann wrote: >=20 > On May 28, 2013, at 7:00 AM, Ryan Stone wrote: >=20 >> On Tue, May 28, 2013 at 5:48 AM, V=E1clav Zeman 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.