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

Re: Bash question: get output as a variable?



On 20100205_135919, Alexey Salmin wrote:
> On Fri, Feb 5, 2010 at 1:20 PM, Javier Barroso <javibarroso@gmail.com> wrote:
> > On Fri, Feb 5, 2010 at 1:06 AM, Stephen Powell <zlinuxman@wowway.com> wrote:
> >> On Thu, 4 Feb 2010 17:42:45 -0500 (EST), Javier Barroso wrote:
> >>> In this case output goes to stderr, so:
> >>>
> >>> tar -zcvf - * --exclude-from $EXCLUDES 2> /tmp/data$$ | openssl ...
> >>
> >> Is that something you just have to find out by trial and error?
> >> I checked the man page for tar, and there's nothing in there about
> >> the -v output being written to stderr. ?I'll take your word for it,
> >> but in the general case, it's hard to tell. ?Since stdout and
> >> stderr both default to the terminal, and since the doc doesn't
> >> say, how else would you know other than by trial and error?
> > If you are using stdout as tar output, including filenames there will
> > corrupt that output, so it is logical that in this case filenames goes
> > to stderr.
> >
> > Sorry my bad english, I hope you understand my opinion
> >
> 
> That's true: programs using stdout for data output certainly have to
> use stderr as a way to report any additional info.
> 
> Alexey

A comment towards 'how would I know':

Traditional Unix and traditional C both made provision for stdin,
stdout, and stderr. When Stroustrup, et al., started working on C++
and its earlier predicessors, someone recognized the need for a fourth
stdXXX, namely stdlog.  I think it was/is a good idea, but it has
never gained enough traction to justify all the changes that would be
required if it were introduced into the POSIX standard. Instead, the
community has kept the name stderr, but changed the usage to something
that might better be named stdmsg, indicating both errors and action
logging. Its the sort of historical development that doesn't get recorded
in any man page (or at least any man page that newbies know about).

HTH
-- 
Paul E Condon           
pecondon@mesanetworks.net


Reply to: