aha! I figured out why journalctl's auto-pager bugs me when git's doesn't (and possible solution)
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