On Tue, 03 Sep 2013 22:41:14 +0200 Alan McKinnon <alan.mckin...@gmail.com> wrote:
> escape sequences in logs (any kind of logs) are basically noise, they
> make search and grep hard to use.
But then why not implement matters that actually make search and grep
easier to use, see the new subject for example. Currently the logs
aren't search and grep compatible because you have no indication where
the last error is and which process has output that; and changing
escape sequences won't do anything about that, this isn't an argument.
> They also make the log impossible to
> read properly if your terminal type is not the same as what was in
> effect when the log was created.
Haven't experienced this, can you give me two attachments from
Bugzilla where at least one of both will display incorrectly for me?
It's easy to say, but I bet it is extremely hard to find; if I can't
find them, they must be very rare. Can you find them?
> And they are essentially candy. A log
> without escapes that you wish had them is still usable.
Since I have to deal with logs a lot, I'd rather work with the most
usable logs; until subject is implemented, escape codes do help me.
> A log with escapes you wish were absent is impossible to use sanely.
Then why do I never have problems with this? Why not strip them?
> The solution is obvious - default to writing plain text to log files
> and give the user an option to enable escapes in the log if {s,}he
> chooses to have it. This does mean you can't use tricks with tee.
What are you trying to solve here? This is not about the users; from
their perspective, I can only hope that the functionality will stay the
same as they don't have a problem with it, some maintainers do...
> I *do* like colorized text on my terminal, but I do believe we ought
> to keep defaults sane - the minimum that could possibly work.
> Everything extra should be optional
Sorry, but I'd rather get the most out of build logs; by being
restricted to minimum output, it takes more time to find the relevant
details from the build log.
If you're trying to more efficiently parse logs; consider adding more
information instead, because dropping information does not really gain.
--
With kind regards,
Tom Wijsman (TomWij)
Gentoo Developer
E-mail address : tom...@gentoo.org
GPG Public Key : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
