Op di 29 aug 2023 om 11:36 schreef Lennart Poettering < lenn...@poettering.net>:
> On Di, 29.08.23 11:20, Cecil Westerhof (cldwester...@gmail.com) 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
