read(1) garbage when input redirected from make incorrectly

[Garrett Cooper]

On Mon, Feb 15, 2010 at 5:45 PM, Jan Mikkelsen <janm at transactionware.com> wrote:
> On 16/02/2010, at 11:55 AM, Garrett Cooper wrote:
>
>> Hi Hackers,
>>    I accidentally reproduced the following after executing read
>> properly in a pipeline with make:
>>
>> [garrcoop at garrcoop-fbsd /usr/home/garrcoop]$ read DESTDIR SRCCONF <
>> /usr/bin/make -V DESTDIR -V SRCCONF
>> bash: read: `-V': not a valid identifier
>> [garrcoop at garrcoop-fbsd /usr/home/garrcoop]$ echo $DESTDIR
>>  ELF
>> [garrcoop at garrcoop-fbsd /usr/home/garrcoop]$ hexdump -C foo
>> 00000000  7f 45 4c 46 01 01 01 0a                           |.ELF....|
>> 00000008
>> [garrcoop at garrcoop-fbsd /usr/home/garrcoop]$
>>
>>    Is 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:
>
>    make -V DESTDIR -V SRCCONF | read DESTDIR SRCCONF
>
> What you are actually doing is feeding the contents of the make binary into:
>
>    read DESTDIR SRCCONF -V DESTDIR -V SRCCONF
>
> and the shell is correctly complaining about '-V' not being a valid identifier, 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 at optimus ~]$ python -c 'import sys; sys.stdin.read()' < make -V
bash: make: No such file or directory
[gcooper at optimus ~]$ perl -e 'while (<>) { print; }' < make -V
bash: make: No such file or directory

Thanks,
-Garrett