bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: read fails on null-byte: v4.1.7 FreeBSD 8.0 (amd64)


From: Chet Ramey
Subject: Re: read fails on null-byte: v4.1.7 FreeBSD 8.0 (amd64)
Date: Thu, 24 Nov 2011 00:08:03 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0

On 11/23/11 9:44 PM, Matthew Story wrote:
> 
> On Nov 23, 2011, at 7:09 PM, Chet Ramey wrote:
> 
>> On 11/23/11 6:54 PM, Matthew Story wrote:
>>> On Nov 23, 2011, at 4:47 PM, Chet Ramey wrote:
>>>
>>>> On 11/23/11 9:03 AM, Matthew Story wrote:
>>>>> [... snip]
>>
>> Yes, sorry.  That's what the "bash treats the line read as a C string"
>> was intended to imply.  Since the line read is a C string, the NUL
>> terminates it and what remains is assigned to the named variables.  I
>> should have used `line' in my explanation instead of `foo'.
> 
> I understand that the underlying implementation of the bash builtins is
> `C', and I understand that `C' stings are NUL terminated.  It seems
> unreasonable to me to expect understanding of this implementation detail
> when using bash to read streams into variables via the `read' builtin.

I took a look around at Posix and some other shells.  Posix passes on
the issue completely: the input to read may not contain NUL bytes at all.
The Bourne shell, from v7 to SVR4.2, uses NUL as a line terminator.  Other
shells, including ksh93, ash and pdksh derivatives like dash and mksh,
discard NUL bytes in read.  zsh doesn't discard NULs and handles them
pretty well, putting them into a variable's value.

The discard behavior seems fairly standard, and I will look at putting it
into the next version of bash.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]