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 [email protected] http://cnswww.cns.cwru.edu/~chet/
