On 8/13/19 2:06 PM, Dmitry Bogatov wrote:
> [2019-08-12 17:45] Jesse Smith
>> Certainly. Attached is a file with the last 20 lines of the
>> /var/boot/log file on a test machine. When I view the log with "less"
>> the output looks normal. When I run the file through "head" "tail" or
>> "cat" the
[2019-08-12 17:45] Jesse Smith
> >> I tried it and the "head", "cat" and "tail" commands mangle the lines
> >> of the log file when escape sequences are not escaped. Output from
> >> "less" is clean though and looks correct.
> > Interesting. Can you please send text that shows this behaviour?
On Tue, 13 Aug 2019, Vincent Lefevre wrote:
> > When I run the file through "head" "tail" or "cat" the "[ ok" part
> > of the message line appears at the beginning of the text.
>
> just because text has been corrupted by bootlogd. That was *not* text
> that was sent the console as documented in
On 2019-08-12 17:45:42 -0300, Jesse Smith wrote:
> On 8/12/19 4:30 PM, Dmitry Bogatov wrote:
> > [2019-08-11 18:08] Jesse Smith
> >> I tried it and the "head", "cat" and "tail" commands mangle the lines
> >> of the log file when escape sequences are not escaped. Output from
> >> "less" is clean
On 8/12/19 4:30 PM, Dmitry Bogatov wrote:
> [2019-08-11 18:08] Jesse Smith
>>> 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
>>
[2019-08-11 18:08] Jesse Smith
> > > 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
control: tags -1 +fixed-upstream
[2019-08-11 17:57] Jesse Smith
> > Please, don't. Issue with '\r' can be resolved by removal of '\r' in
> > `bin:lsb-base'.
>
> Okay, I'll do an option for completely unfiltered and other tools and be
> adjusted to match.
Thank you very much.
> > With
On 2019-08-12 11:14:48 -0300, Jesse Smith wrote:
> On 8/12/19 4:20 AM, Vincent Lefevre wrote:
> > On 2019-08-11 17:57:18 -0300, Jesse Smith wrote:
> >> For situations like this where you already have a log with escape
> >> characters in it, you can fix the output by using the readbootlog
> >>
On 8/12/19 4:20 AM, Vincent Lefevre wrote:
> On 2019-08-11 17:57:18 -0300, Jesse Smith wrote:
>> For situations like this where you already have a log with escape
>> characters in it, you can fix the output by using the readbootlog
>> program, which is part of the sysvinit suite. It cleans out
On 2019-08-11 18:08:55 -0300, Jesse Smith wrote:
> I wasn't speaking theoretically. I tried it and the "head", "cat" and
> "tail" commands mangle the lines of the log file when escape sequences
> are not escaped.
There might be problems with some implementations of these utilities
due to binary
On 2019-08-11 17:57:18 -0300, Jesse Smith wrote:
> For situations like this where you already have a log with escape
> characters in it, you can fix the output by using the readbootlog
> program, which is part of the sysvinit suite. It cleans out most of the
> control characters so the log looks
On Sun, 11 Aug 2019 17:47:17 + Dmitry Bogatov wrote:
> > 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
> Please, don't. Issue with '\r' can be resolved by removal of '\r' in
> `bin:lsb-base'.
Okay, I'll do an option for completely unfiltered and other tools and be
adjusted to match.
> With filtering as implemented now `/var/boot/log' looks bad both in editor
> and terminal. Example:
>
> Fri
[2019-08-08 19:24] Jesse Smith
> On Thu, 08 Aug 2019 20:21:50 + 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
> > >
[2019-08-08 19:24] Jesse Smith
>
> part 2 text/plain1753
> On Thu, 08 Aug 2019 20:21:50 + 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
[2019-08-08 19:24] Jesse Smith
>
> part 2 text/plain1753
> On Thu, 08 Aug 2019 20:21:50 + 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
[2019-08-08 19:24] Jesse Smith
>
> part 2 text/plain1753
> On Thu, 08 Aug 2019 20:21:50 + 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
On 2019-08-08 19:24:23 -0300, Jesse Smith wrote:
> 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?
I think so. Filter \r out, which is
On Thu, 08 Aug 2019 20:21:50 + 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).
> >
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
On Wed, Aug 07, 2019 at 03:11:02AM +0200, Vincent Lefevre wrote:
> On 2019-08-06 15:10:25 +, Dmitry Bogatov wrote:
> > [2012-05-20 11:37] "Marc Dequènes (Duck)"
> > > Fancy output should be deactivated or handled differently, but we
> > > really need the ok/fail/warn status displayed
On 2019-08-06 15:10:25 +, Dmitry Bogatov wrote:
> [2012-05-20 11:37] "Marc Dequènes (Duck)"
> > Coin,
> >
> > 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
Coin,
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).
Regards.
--
Marc
Package: bootlogd
Version: 2.88dsf-22.1
Severity: wishlist
/var/log/boot contains escape sequences, which make it difficult to
read, e.g.
Thu May 3 14:35:20 2012: [] Setting parameters of disc:
(none)^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0c.
They should be filtered out
24 matches
Mail list logo
