bug-bash
[Top][All Lists]
Advanced

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

Re: Regression -- can't read input w/stderr redirect


From: Chet Ramey
Subject: Re: Regression -- can't read input w/stderr redirect
Date: Sun, 18 Jun 2017 18:39:01 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1

On 6/18/17 5:02 PM, L A Walsh wrote:

>  int dpi=$(ord $(<"$pixels_path" 2>/dev/null))
> 
> 
> This used to work but now works _unreliably_.
> 
> (NOTE: I know that function won't work for values over 255,
> but hasn't been a problem yet, so haven't needed to fix it).
> 
> Tried running it interactively, and got:
> 
>  > int dpi=$(ord $(<"$pixels_path" ))           -bash: warning: command
> substitution: ignored null byte in input

These are not the same command. Eduado explained why this matters.

> 
> I've always expected the '0' bytes to terminate input so
> my "ord" only picked up the 1st character, but I know
> about the added message.

Bash has always stripped NULL bytes. Now it tells you it's doing it.

> 
> Side question: Why display that message if there are only
> NUL's at the end?  I would think it normal for bash to
> use and read NUL terminated strings.  

This is very uncommon. Most Unix utilities use newline-terminated
lines.


> So why the err message
> in that case?  FWIW, if the null bytes are anywhere BUT
> the end, then I'd see that as an error, but usually with
> C and bash, a NUL-byte terminating a string seems a bit
> "unremarkable". (no?)

Internally, maybe, but not when dealing with external utilities.

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



reply via email to

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