Date: Thu, 04 Apr 2013 09:42:55 -0500 From: "Mark Felder" <feld@feld.me> To: "Teske, Devin" <Devin.Teske@fisglobal.com>, "Devin Teske" <dteske@freebsd.org> Cc: "<freebsd-questions@freebsd.org>" <freebsd-questions@freebsd.org> Subject: Re: OT: posix sh problem Message-ID: <op.wu0tttba34t2sn@tech304.office.supranet.net> In-Reply-To: <13CA24D6AB415D428143D44749F57D7201EF2411@ltcfiswmsgmb21> References: <op.wu0nsgsf34t2sn@tech304.office.supranet.net> <13CA24D6AB415D428143D44749F57D7201EF2411@ltcfiswmsgmb21>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 04 Apr 2013 08:54:30 -0500, Teske, Devin <Devin.Teske@fisglobal.com> wrote: > Wait, you can't? Then I've been doing something wrong all these years… > #!/bin/sh > printf "line1\nline2\n" | while read line > do > echo "line=[$line]" > done You sort-of can, but it's not portable at all. As detailed here: http://www.etalabs.net/sh_tricks.html >> One common pitfall is trying to read output piped from commands, such >> as: >> foo | IFS= read var >>POSIX allows any or all commands in a pipeline to be run in subshells, >> and which command (if any) runs in the main shell varies greatly between >> implementations — in particular Bash and ksh differ here. The standard >> idiom for overcoming this problem is to use a here document: >> >> IFS= read var << EOF >> $(foo) >> EOF I was having problems with the variables magically becoming empty, remembered I had Rich's site bookmarked, checked to see if it mentioned and it was. I'll admit there's a high chance that due to lack of sleep user error was the culprit.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?op.wu0tttba34t2sn>