help-bash
[Top][All Lists]
Advanced

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

Re: [Help-bash] shell redirection


From: Bob Proulx
Subject: Re: [Help-bash] shell redirection
Date: Wed, 19 Oct 2016 16:04:48 -0600
User-agent: NeoMutt/20161014 (1.7.1)

Greg Wooledge wrote:
> Christof Warlich wrote:
> > Thanks for the quick response: Thus, as much as I understand,
> > a line-oriented piped reader approach would avoid mixing output
> > of stdout and stderr _within_ lines, but the sequence of whole lines
> > w.r.t. stdout and stderr may still be garbeled ...?!
> 
> Yes, that's correct.  Imagine the two readers each receive one line,
> a microsecond apart.  If the kernel's scheduling causes one of them
> to delay by 2 microseconds, it'll write its line last.  Over the
> course of a very long run, this could cause a few unexpected line
> order switches.

Yes.  In addition to that, which regards line buffered output, there
will be programs that buffer output into larger chunks bigger than
lines to stdout.  The result is always based upon the underlying chunk
that was written all at once.  If that is a line then it is a line.
If it is a 1024 byte chunk then that is what it is too.  For many
scripts they may only ever deal with line buffered output.  But others
might run programs that write bigger chunks.

> > That's really rather disappointing: My idea was to make the
> > sequence of commnds executed by my scripts (and possible
> > errors) visible on the terminal by employing set -x, while writing
> > a logfile containing _all_ information for "debugging" purpose
> > if needed.
> 
> This seems strange to me.  I would expect the set -x output to be
> much greater in size than the regular output, for most scripts.
> So, suppressing stdout on the terminal doesn't seem like it would
> help you a lot.

A filter program like grep, sed, awk, often produces as much output as
input.  In which case the -x output would be small.  But Unix filters
are designed the way they are intentionally to support a particular
style.  Input goes through the filter to the output.  Errors are left
directed to the tty so that they are visible.  The exit code reflects
the error status regardless of any written stderr information.

> > This would be particularly usefull for scripts that produce loads
> > of output, e.g. when generating toolchains.
> 
> I guess I never deal with that kind of script.

I think the usual approach is to modify the program to write an
explicit log file if that is specifically desired.  But if it is a
filter like program like grep, sed, awk then just worry about the
errors only.

Bob



reply via email to

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