Re: Why are the priorities of stdout and stderr the same

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

 



Op di 29 aug 2023 om 11:36 schreef Lennart Poettering <lennart@xxxxxxxxxxxxxx>:
On Di, 29.08.23 11:20, Cecil Westerhof (cldwesterhof@xxxxxxxxx) wrote:

> Also: everything has a timestamp, so there is in my opinion when you choose
> to take them apart no big problem.

For stream connections like those used for stdout/stderr, lines do not
come with timestamps. We add them on the reception side, which is too late.
 
I did not know that. I understand it now.

 
> > > To get what is send to stderr I had to do:
> > >     journalctl -p 6 -u aptCacheUsage.service
> > >
> > > which gave beside a lot of other things the things send to stdout.
> > >
> > > Now I have two different statements I can do:
> > >     journalctl -p 3 -u aptCacheUsage.service
> > >
> > > But it would be nice if I did not need two different statements (and the
> > > logic around that) for that.
> >
> > Still not getting what you are trying to say here.
> >
>
> Often I am only interested in what is sent to stderr and do not want what
> is sent to stdout. When both have the same log level I can not really
> filter on messages sent to stderr. At the moment I want to see the messages
> sent to stderr, I will also get the messages sent to stdout because they
> have the same error level.

I agree with that usecase, and we have discussed this many times
before, but we couldn#t come up with a nice way to make everything
work: proper ordering and distintion of stdout/stderr.

I agree that the default behaviour is the right one. But why not give people the possibility to override this behaviour? When they override it themselves, they cannot complain that they lose ordering.


--
Cecil Westerhof

[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux