[Toybox] [PATCH] Implement "dmesg -w".

[Rob Landley]

On 11/15/2016 12:11 PM, enh wrote:
> (sorry, was afk, including linux plumbers, keeping up the tradition of
> us going in alternating years :-) )

I flew back from Tokyo last tuesday to vote (for all the good it did),
took a red-eye to Minneapolis thursday morning and left my netbook
charger on the couch (sigh), and am now trying to catch up on email
before I have to fly out again (not sure where yet, but _4_ possible
destinations pending).

I committed your patch for this one, but have a note near the top of my
todo list to try to clean it up...

> On Sun, Oct 30, 2016 at 6:00 PM, Rob Landley <rob at landley.net> wrote:
>>> Since I'm here, add the fancy colors from modern dmesg and the -C flag.
>>
>> There's no way _not_ to color the output except piping it through cat.
> 
> yeah, it's the usual --color=[never|auto|always]. i was going to copy
> what ls did (as the main user of --color=[never|auto|always]), but it
> looked like ls doesn't quite work like that yet either, and i wasn't
> sure what your plan was there?

I did 2/3 of the work for grep --color and got interrupted, yet again.
Sigh. (Toybox would be so much easier if it didn't get swap-thrashed by
higher priority stuff.)

But yeah, I should have a coherent --color policy. Throw it on the todo
heap. (wget, grep, ls... what else?)

Hang on, seriously?

  $ zgrep -R '[-]-color' /usr/share/man
  /bin/zgrep: -R: option not supported
  $ zgrep -r '[-]-color' /usr/share/man
  /bin/zgrep: -r: option not supported

Grrr. I have a todo item to do the zwrappers for various commands, but I
thought they all just had the same options as the other ones and just
took a different input format?

(Really it should autodetect the input type, but the logical thing to do
would be have a -z or something to tell it that, but which one? tar uses
-a but grep -a means --text. -z is regularly used to mean input/output
is nul terminated instead of newlines... and I don't want it to be -z
anyway because bzip and xz and so on should _also_ get supported.
Hmmm... One of the "semi-aesthetic problem which is hard because it
doesn't really MATTER enough to have an obvious solution, so all
approaches I can think of feel wrong". There should be a word for that.)

Oh well, throw it on the todo heap. Having zname prefixes isn't _that_
bad. (Although zcat and bzcat and xzcat just differing by file format
makes baby Rob Pike cry. Maybe I can make one "z" autodetect the input
type. The code is needed for "tar" anyway. But it implies the
decompression code should be in lib, not in toys/*/zcat.c and similar...)

>> Sigh, I need to upgrade lib/args.c to have a syntax to say "these
>> letters all conflict with the _first_ letter but not each other". [$abc]
>> maybe? Throw it on the todo heap... (Still neck-deep in GPS-land for
>> another week. Learning to calculating the G2 register of the LFSR for a
>> given PRN value. No really, those all mean something. Unfortunatley the
>> example program the hardware engineer wrote for us was written in bad perl.)
>>
>> I can't easily test legacy_mode() but it looks like TT.size is never set
>> if you don't specify -s (defaults to 0) and it'll perror_exit("klogctl")
>> in that case?
> 
> yeah, some of the options are incompatible, and whether or not you can
> use -w depends on your kernel version. i assume you still want to
> support "old" (pre-3.5) kernels?
> 
> i wanted the new implementation to get plenty of use to help shake the
> bugs out, but it might make sense -- if we're keeping the pre-3.5
> support -- to only use it with -w.

Before this, dmesg was so simple that if an implementation needed plenty
of use to shake bugs out, they were doing it wrong. And then the systemd
guys got to it.

Rob