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

Dmitry Bogatov KAction at debian.org
Sun Aug 11 18:47:17 BST 2019

[2019-08-08 19:24] Jesse Smith <jsmith at resonatingmedia.com>
> On Thu, 08 Aug 2019 20:21:50 +0000 Dmitry Bogatov wrote:
> >
> > control: tags -1 +upstream
> >
> > [2019-08-07 05:13] Adam Borowski
> > > [...]
> > > > 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.
> >
> > Jesse, there seems to be demand on turning-off escape sequence filtering
> > in bootlogd. Can you please make it configurable?
> It is pretty easy to make an option for printing the escape sequences to
> the log file. This will allow tools like "less" to print the boot log
> with its colour codes.
> I'd like to point out though that with such an option enabled, it is
> going to result in some weird output. If all escape sequences are
> printed to the file, tools like "less" can handle it, but other (more
> raw) text manipulation tools such as "head" and "tail" will end up
> mangling the lines.

No. When you output raw escape sequences on terminal, they will be
interpreted by terminal, so `head', `tail' and `grep' output will be
readable and colored. Pager `less' with -R option also interpret escape

Obliviously, editors like `vi' or `emacs' do not interpret sequences,
so logs in editor will not look pretty.

All above does not apply to dumb terminals, but who uses them?

> This is partly because escape characters include
> positional instructions like '\r' for carriage-return.
> In other words, if we make the boot log completely unfiltered, lines in
> "less" will display properly, but using "cat", "head" or "tail" will
> result in mangled lines that look like this:
> Thu Aug 8 19:06:30 2019:
> [ ok ug 8 19:06:30 2019: [... starting ]

Looks like your terminal interpret '\r' incorrectly. What does following
command print on your terminal?

 $ bash -c "printf 'foo\rbar'"

> I'm not sure we want to do that. Perhaps the ideal would be a small
> degree of filtering to remove the positional control characters (like
> '\r') while leaving the rest in to allow for colour to be displayed?

Please, don't. Issue with '\r' can be resolved by removal of '\r' in

With filtering as implemented now `/var/boot/log' looks bad both in editor
and terminal. Example:

  Fri Feb 22 18:42:36 2019: [....] Not activating swap on logical volume. ...??7[warn8?? (warning).
  Fri Feb 20 18:42:36 2019: [....] Starting early crypto disks...sda3_crypt (running)...??7[ ok 8??done.

Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

More information about the Debian-init-diversity mailing list