aha! I figured out why journalctl's auto-pager bugs me when git's doesn't (and possible solution)

Matthew Miller mattdm at fedoraproject.org
Wed Oct 17 23:57:21 UTC 2012


Again, this is with the prefix that this isn't a big deal; it's a matter of
polish. But, here's the difference between `man` and `git log` automatically
sending output to a pager:

Man is a document reader. When you run it, you start at the top and read
down. A pager is natural.

The git log command is _reverse sorted_. So, again, the most useful and
relevant information is at the top. Cool.

With log information, unless explicitly searching, it's almost always the
_end_ that's most interesting. So, every time I run it, I'm looking at
"boring" old information, and have to scroll to the bottom (with `G` or
`End`). Not so cool.

If it just spit out the entire information, it'd all scroll past, and I
could use my terminal's buffer to scroll back, or decide to pipe to a
command (a typical log-checking workflow would be to use grep, but
journalctl's filters are helpful here).

So, possible solutions:

  - reverse-sort the log entries, a la `git log` (I don't think anyone
    really wants this)

  - don't auto-page; enable that with a flag (I know Lennart does not
    like this; okay, fair enough)

  - change the default less options to include +G, which jumps to the
    end of the file. (I'd also suggest adding the -M option to show
    line numbers -- it's nice, and makes it more clear that scrolling
    up is an option)



-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm at fedoraproject.org>


More information about the devel mailing list