From owner-freebsd-hackers@FreeBSD.ORG Fri May 31 18:00:00 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D9C53797 for ; Fri, 31 May 2013 18:00:00 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-bk0-x235.google.com (mail-bk0-x235.google.com [IPv6:2a00:1450:4008:c01::235]) by mx1.freebsd.org (Postfix) with ESMTP id 6FF1E2F3 for ; Fri, 31 May 2013 18:00:00 +0000 (UTC) Received: by mail-bk0-f53.google.com with SMTP id mx10so892101bkb.40 for ; Fri, 31 May 2013 10:59:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:subject:date:content-type :content-transfer-encoding:in-reply-to:references:x-mailer; bh=6nwhI8PWqLRuwfiBkFKCaCBcXTD1W7639GGoEafjBzg=; b=xindJZy0OQlk1AisEWXfowPItjHEoYw0YBtTE333IVT5cKzGwtQ4q2ScUnFHKbN4VH /rTV/X0PSIoWIpBO7PijUcb4VTB5ticUDORMciVEwIwqnTts+vsSZADbAE2evZvs2BA2 kqLPDbZc7HpVov+F+oDn5mzEIAXAdqQp7MsVnTFj0di96NkwvhLDaCHCSb1bWcrWqLWE OgQhNWQRakz2LZbBnj+uQtO8xiRkdKQAQ7oU8vpIeUOVWVio68wbgZ9Sd4bmAzxMFc7Z xrkNuPGh1Vrgx72B31iPrV13pL00ppIhc2jU2u9EwP0Rs0n8INpna3vfwsZULp5gjdxD 3p9w== X-Received: by 10.204.187.209 with SMTP id cx17mr3745277bkb.143.1370023199497; Fri, 31 May 2013 10:59:59 -0700 (PDT) Received: from DOMYPC ([82.193.208.225]) by mx.google.com with ESMTPSA id tl1sm15598246bkb.7.2013.05.31.10.59.57 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 31 May 2013 10:59:58 -0700 (PDT) Message-ID: <20130531.175959.745.2@DOMY-PC> From: rank1seeker@gmail.com To: "Jilles Tjoelker" , hackers@freebsd.org Subject: Re: /bin/sh => STDIN & functions, var scope messing Date: Fri, 31 May 2013 19:59:59 +0200 Content-Type: text/plain; charset="Windows-1250" Content-Transfer-Encoding: quoted-printable In-Reply-To: <20130530223031.GA1672@stack.nl> References: <20130527.194235.693.1@DOMY-PC> <20130530223031.GA1672@stack.nl> X-Mailer: POP Peeper (3.8.1.0) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 18:00:00 -0000 Redirections > and >> don't put it in a subshell.=0D=0AOnly pipe |, which = means only STDIN affects/triggers this behaviour.=0D=0ADoes < operator = also does it, as it is also STDIN?=0D=0A=0D=0AAnyway, I don't care for = executing binaries, but I do care if that is part of sh's code, as = function is.=0D=0AIt messes var scopes.=0D=0A=0D=0AAnd finally if we take = into account this:=0D=0A=0D=0A> For example=85 in pc-sysinstall=85=0D=0A> = =0D=0A> ./backend/functions-extractimage.sh- tar cvf - . 2>/dev/null = | tar -xpv -C ${FSMNT} ${TAROPTS} -f - 2>&1 | tee -a = ${FSMNT}/.tar-extract.log=0D=0A> ./backend/functions-extractimage.sh: = if [ $? -ne 0 ]=0D=0A> =0D=0A> That's a big no-no.=0D=0A> =0D=0A> 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 = failure in your checking of $?=0D=0A> =0D=0A> 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.=0D=0A> =0D=0A> I call this the = "piped return-status conflation issue". Basically=85 anytime 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:=0D=0A> =0D=0A> (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)=0D=0A> = =0D=0A> (b) undo the pipe-chain and store your results for incremental = processing=85 checking the return status after each filter.=0D=0A> = =0D=0A> -- =0D=0A> Devin=0D=0A=0D=0A=0D=0Ash's behaviour must be changed = regarding pipeing=0D=0A=0D=0A> > Curious. Which of the two behaviours is = POSIXly correct?=0D=0A> =0D=0A> Both. As per XCU 2.12 Shell Execution = Environment, each command in a=0D=0A> multi-command pipeline may or may = not be executed in a subshell=0D=0A> environment.=0D=0A> =0D=0A> = Behaviour different from our sh is most often encountered in the = various=0D=0A> versions of the real Korn shell (ksh88 and ksh93), which = execute the=0D=0A> last command in a pipeline in the current shell = environment.=0D=0A> =0D=0A> If things like jobs | cat work, that can = also be explained using this=0D=0A> rule.=0D=0A> =0D=0A> -- =0D=0A> = Jilles Tjoelker=0D=0A>=0D=0A=0D=0A=0D=0ADomagoj Smol=E8i=E6=0D=0A