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: Robert Elz
Subject: Re: Regression -- can't read input w/stderr redirect
Date: Mon, 19 Jun 2017 05:14:00 +0700

    Date:        Sun, 18 Jun 2017 14:02:05 -0700
    From:        L A Walsh <bash@tlinx.org>
    Message-ID:  <5946EA4D.8030004@tlinx.org>


  | 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.

Files with nuls are not normal, they're usually some kind of binary
(a.out, jpeg, ...) which most of the time you don't want to read in
a sh script.


  |   int dpi=$(ord $(<"$pixels_path" 2>/dev/null))
  |   # no error message, but also got (in my script):

I think you'll find that's because the $(<file) hack (and a hack it is)
only works when that is the *only* thing in the comamnd substitution, put
anything else at all in there, and you just get a regular command sub
which does exactly what you asked it to (in this case, open a couple of
files, do nothing with them, and then exit, with no output).

Apart from that, the stderr redirection isn't in the right place anyway.
If the elided cat was there, that would remove messages from cat (about
not being able to open the file) but it is in the wrong place to handle
the error about the result of the $( ) having a nul in it.   That would
need to be more like

        int dpi=$(ord $(<"$pixels_path")) 2>/dev/null

I suspect (though I haven't bothered to check it - redirecting errs
from the sh running the script itself has typically been difficult to
achieve.)

kre

ps: I see Eduardo Bustamante has just said almost the same thing with
more detail...




reply via email to

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