Date: Thu, 4 Apr 2013 15:04:41 +0000 From: "Teske, Devin" <Devin.Teske@fisglobal.com> To: Mark Felder <feld@feld.me> Cc: Devin Teske <dteske@freebsd.org>, "<freebsd-questions@freebsd.org>" <freebsd-questions@freebsd.org> Subject: Re: OT: posix sh problem Message-ID: <13CA24D6AB415D428143D44749F57D7201EF2627@ltcfiswmsgmb21> In-Reply-To: <op.wu0tttba34t2sn@tech304.office.supranet.net> References: <op.wu0nsgsf34t2sn@tech304.office.supranet.net> <13CA24D6AB415D428143D44749F57D7201EF2411@ltcfiswmsgmb21> <op.wu0tttba34t2sn@tech304.office.supranet.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 4, 2013, at 7:42 AM, Mark Felder wrote: > On Thu, 04 Apr 2013 08:54:30 -0500, Teske, Devin <Devin.Teske@fisglobal.c= om> wrote: >=20 >> Wait, you can't? Then I've been doing something wrong all these years=85 >> #!/bin/sh >> printf "line1\nline2\n" | while read line >> do >> echo "line=3D[$line]" >> done >=20 > You sort-of can, but it's not portable at all. As detailed here: http://w= ww.etalabs.net/sh_tricks.html >=20 >>> One common pitfall is trying to read output piped from commands, such a= s: >>> foo | IFS=3D read var >>> POSIX allows any or all commands in a pipeline to be run in subshells, And for most purposes that's fine. Read-on=85 >>> and which command (if any) runs in the main shell varies greatly betwee= nimplementations =85 that is only if you truly need the variables to be read into the main s= hell. This is most always not what you want. The page you linked about doesn't talk about the special case of "while", i= n example: foo | IFS=3D while read var On the back-end nothing changes (the same caveat applies -- variables set o= n the right side of the pipe may not be available to the main shell; as-per= the quoted text). However, the high-level task changes from: I want to read some text from a pipe into some variables to instead: I want to read some text from a pipe and process it word-by-word (in your = case) and act on the words in a loop So in other words=85 the only reason for wanting the variables in the main = shell is if you want to act on the last set of variables for the last line = after the loop has run (and presumably already processed the last line). Th= is is what I am saying anyone will rarely ever want. In other words, once t= he loop (potentially running in a sub-shell) has completed, you likely don'= t care about the variable contents and are willing to throw them away anyho= w. >>> =97 in particular Bash and ksh differ here. The standardidiom for overc= oming this problem is to use a here document: >>>=20 >>> IFS=3D read var << EOF >>> $(foo) >>> EOF >=20 But you're not processing a single line; you're processing the entire input= at-once and performing an action (writing to the screen) that also doesn't= care whether it's in a sub-shell or not. SO=85 I say rock-on with the original syntax. It's portable. You don't need those= vars when the loop ends. >=20 > I was having problems with the variables magically becoming empty, rememb= ered I had Rich's site bookmarked, checked to see if it mentioned and it wa= s. I'll admit there's a high chance that due to lack of sleep user error wa= s the culprit. I'm interested in why you need the variables after the loop has completed. = Put your code in the loop where the variables are defined and have values. --=20 Devin _____________ 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?13CA24D6AB415D428143D44749F57D7201EF2627>