Date: Tue, 16 Feb 2010 09:01:29 -0800 From: Garrett Cooper <yanefbsd@gmail.com> To: Jan Mikkelsen <janm@transactionware.com> Cc: FreeBSD-Hackers <freebsd-hackers@freebsd.org> Subject: Re: read(1) garbage when input redirected from make incorrectly Message-ID: <7d6fde3d1002160901r600bb514u4a3219d2e59b16aa@mail.gmail.com> In-Reply-To: <BC288C06-614D-4097-901E-5CBECCCC215F@transactionware.com> References: <364299f41002151649y2e4d4120p918759afb1fd8f6c@mail.gmail.com> <7d6fde3d1002151655q184c8a21k8a0c6c07b9b0ae79@mail.gmail.com> <BC288C06-614D-4097-901E-5CBECCCC215F@transactionware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Feb 15, 2010 at 5:45 PM, Jan Mikkelsen <janm@transactionware.com> w=
rote:
> On 16/02/2010, at 11:55 AM, Garrett Cooper wrote:
>
>> Hi Hackers,
>> =A0 =A0I accidentally reproduced the following after executing read
>> properly in a pipeline with make:
>>
>> [garrcoop@garrcoop-fbsd /usr/home/garrcoop]$ read DESTDIR SRCCONF <
>> /usr/bin/make -V DESTDIR -V SRCCONF
>> bash: read: `-V': not a valid identifier
>> [garrcoop@garrcoop-fbsd /usr/home/garrcoop]$ echo $DESTDIR
>> =A0ELF
>> [garrcoop@garrcoop-fbsd /usr/home/garrcoop]$ hexdump -C foo
>> 00000000 =A07f 45 4c 46 01 01 01 0a =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 |.ELF....|
>> 00000008
>> [garrcoop@garrcoop-fbsd /usr/home/garrcoop]$
>>
>> =A0 =A0Is this an issue to be concerned about apart from cosmetic noise,
>> i.e. potential buffer access problem? I see the same garbage from
>> bash/coreutils on RHEL 4.6 as well as read(1) and /bin/sh on FreeBSD
>> with RELENG_8, so the issue appears to be consistent on multiple
>> OSes...
>> Thanks,
>> -Garrett
>
> I think you meant to type:
>
> =A0 =A0make -V DESTDIR -V SRCCONF | read DESTDIR SRCCONF
>
> What you are actually doing is feeding the contents of the make binary in=
to:
>
> =A0 =A0read DESTDIR SRCCONF -V DESTDIR -V SRCCONF
>
> and the shell is correctly complaining about '-V' not being a valid ident=
ifier, and populating DESTDIR with data it got from the binary.
Yes, now it all makes sense to me. It's just interesting why read
(1) is the only thing I've found (so far) that has this behavior, but
it's probably a biproduct of how it scans its arguments on stdin:
[gcooper@optimus ~]$ python -c 'import sys; sys.stdin.read()' < make -V
bash: make: No such file or directory
[gcooper@optimus ~]$ perl -e 'while (<>) { print; }' < make -V
bash: make: No such file or directory
Thanks,
-Garrett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7d6fde3d1002160901r600bb514u4a3219d2e59b16aa>