Bug#672361: bootlogd: escape sequences should be filtered out

Adam Borowski kilobyte at angband.pl
Wed Aug 7 04:13:34 BST 2019

On Wed, Aug 07, 2019 at 03:11:02AM +0200, Vincent Lefevre wrote:
> On 2019-08-06 15:10:25 +0000, Dmitry Bogatov wrote:
> > [2012-05-20 11:37] "Marc Dequènes (Duck)" <duck at duckcorp.org>
> > > Fancy output should be deactivated or handled differently, but we  
> > > really need the ok/fail/warn status displayed properly. Having the  
> > > result of escape commands would be easier to parse than just removing  
> > > escape codes ("[ok] stuff" instead of "[....] stuff ok").
> > 
> > Nowdays bootlogd filters-out escape characters, so closing bug. I
> > believe it was introduced in 2.91.
> Filtering out escape characters is useless without filtering out
> the whole escape sequence. Actually, this is even worse, as this
> prevents the escape sequences from being interpreted by the
> terminal.

Aye, if you want to convert to plain text, you need to drop the whole
sequence.  A way to do so that handles any sequences that appear in regular
files is in "ansi2txt" (package colorized-logs).  That does remove rather
than interpret them, though.

Interpreting just a few select sequences might be reasonable; I've done this
before.  Still, you'd need a line buffer.

> > I agree, that "[..] stuff ok" is not very readable, but it is not
> > reasonable to expect bootlogd to actually interpret control sequences.
> Then it should not filter out anything.


> > I think it should be fixed in bin:lsb-base by changing style of
> > decoration: placing [ok] at end of line, not beginning.
> Now that systemd became the default, the problem has been solved by
> using it instead of sysvinit + bootlogd

That's not a "solution".

> a /var/log/boot.log file is
> generated where nothing is filtered out, so that the file is readable
> with "cat" or "less" (and text is colored).

I don't think files in /var/log/ should be anything but plain text -- at
least unless colorized-logs becomes essential :þ and/or less defaults to
-R.  But until a solution is implemented, I agree that leaving binaryish
control codes intact is better than corrupting them.

⣾⠁⢠⠒⠀⣿⡁ Debian is one big family.  Including that weird uncle
⢿⡄⠘⠷⠚⠋⠀ and ultra-religious in-laws.

More information about the Debian-init-diversity mailing list