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 mattdm@fedoraproject.org writes:
- don't auto-page;
yes; that's the best solution. The auto-pager is perhaps the most annoying feature of systemd. I have no problem in scrolling back some pages in my terminal with shift-pgup, but having a status request block (plain 'systemctl' or 'journalctl' request a status) is just broken.
Or, do you want that e.g. the 'ls -l' output gets auto-paged?
I disabled it be setting an empty SYSTEMD_PAGER on my systems; but this breaks piping into a pager.
E.g. 'systemctl | less -S' or 'journalctl | less -S' is useless because most information were removed. I have to remember non-consistent options now, e.g. 'systemctl -a' has a complete different meaning than 'journalctl -a'.
Hence, the systemd tools should follow Unix/Linux tradition and specialize on their core functionality and avoid implementing "features" breaking user experience. There are other tools like 'less' which are much better suited for paging program output and concepts like pipes are well known and used at thousands of other places.
Enrico
On 2012-10-18 11:35, Enrico Scholz wrote:
Hence, the systemd tools should follow Unix/Linux tradition and specialize on their core functionality and avoid implementing "features" breaking user experience. There are other tools like 'less' which are much better suited for paging program output and concepts like pipes are well known and used at thousands of other places.
+1, FWIW
On Thu, 2012-10-18 at 10:35 +0200, Enrico Scholz wrote:
Matthew Miller mattdm@fedoraproject.org writes:
- don't auto-page;
yes; that's the best solution. The auto-pager is perhaps the most annoying feature of systemd. I have no problem in scrolling back some pages in my terminal with shift-pgup, but having a status request block (plain 'systemctl' or 'journalctl' request a status) is just broken.
I don't really look at it that way. Let's see, how to put it...
Okay, so with the old system, I don't recall *ever* doing 'cat /var/log/messages'. I always, always either less'ed it or grep'ped it. So to me it makes sense for journalctl to page by default, because that's what I always wanted to do with the logs anyway. I guess the assumption might have been that most people use logs like me, and hence that's why journalctl is designed the way it is.
Did/do you usually less /var/log/messages? Or did you usually cat it?
Or, do you want that e.g. the 'ls -l' output gets auto-paged?
Thinking about this case, when I'm doing an ls -l which I know will be long, I usually wind up trying to order it in such a way that what I want to see will be at the bottom (classically, ls -ltr)...that doesn't really work with journals. How about you?
On 10/18/2012 01:29 PM, Adam Williamson wrote:
Okay, so with the old system, I don't recall *ever* doing 'cat /var/log/messages'. I always, always either less'ed it or grep'ped
...
Did/do you usually less /var/log/messages? Or did you usually cat it?
Or, do you want that e.g. the 'ls -l' output gets auto-paged?
tail -f, about half of the time...
On Thu, Oct 18, 2012 at 01:41:59PM -0400, Przemek Klosowski wrote:
Okay, so with the old system, I don't recall *ever* doing 'cat /var/log/messages'. I always, always either less'ed it or grep'ped Did/do you usually less /var/log/messages? Or did you usually cat it?
Or, do you want that e.g. the 'ls -l' output gets auto-paged?
tail -f, about half of the time...
And, there _is_ `journalctl -f`, which does just what you'd expect.
On 10/18/2012 01:41 PM, Przemek Klosowski wrote:
On 10/18/2012 01:29 PM, Adam Williamson wrote:
Okay, so with the old system, I don't recall *ever* doing 'cat /var/log/messages'. I always, always either less'ed it or grep'ped
...
Did/do you usually less /var/log/messages? Or did you usually cat it?
Or, do you want that e.g. the 'ls -l' output gets auto-paged?
tail -f, about half of the time...
BTW, I hope that journald will allow doing the equivalent of
tail -f /var/log/**
This would be tricky during the transition when some programs will still use /var/log/xxx files and some will go through journald. Sort of like currently dmesg working differently than /var/log/* files (I keep making the mistake of 'tail dmesg'/'less dmesg').
On Thu, Oct 18, 2012 at 01:50:38PM -0400, Przemek Klosowski wrote:
BTW, I hope that journald will allow doing the equivalent of tail -f /var/log/**
That is effectively what 'journalctl -f' does by default.
This would be tricky during the transition when some programs will still use /var/log/xxx files and some will go through journald. Sort
Effectively, any server that doesn't use syslog now.
of like currently dmesg working differently than /var/log/* files (I keep making the mistake of 'tail dmesg'/'less dmesg').
Here, you are in luck -- journald handles those messages. (By default in F18, optionally in F17.)
Am 18.10.2012 19:29, schrieb Adam Williamson:
On Thu, 2012-10-18 at 10:35 +0200, Enrico Scholz wrote:
Matthew Miller mattdm@fedoraproject.org writes:
- don't auto-page;
yes; that's the best solution. The auto-pager is perhaps the most annoying feature of systemd. I have no problem in scrolling back some pages in my terminal with shift-pgup, but having a status request block (plain 'systemctl' or 'journalctl' request a status) is just broken.
I don't really look at it that way. Let's see, how to put it...
Okay, so with the old system, I don't recall *ever* doing 'cat /var/log/messages'. I always, always either less'ed it or grep'ped it. So to me it makes sense for journalctl to page by default
and i am doing "tail -n 500 -f /var/log/messages" or whatever logfle i want to watch since years because i want to see what happened before, can scroll up and watch what is going on
the same works for "tail -n 500 -f /var/log/messages | grep whatever" for me i prcatically NEVER use any pager!
so you see how different workflows are and that is why the unix-principle is "basic tools and stick them together" this way yours and mine way to do things are equally supported
On Thu, Oct 18, 2012 at 07:46:46PM +0200, Reindl Harald wrote:
and i am doing "tail -n 500 -f /var/log/messages" or whatever logfle i want to watch since years because i want to see what happened before, can scroll up and watch what is going on
This will work *right now* with journald, with almost identical semantics:
journalctl -n500 -f
(No space allowed after then -n.)
the same works for "tail -n 500 -f /var/log/messages | grep whatever" for me i prcatically NEVER use any pager!
There's a bug with that right now, but theoretically should work. You can also use journalctl's built-in filtering, which does matches on fields.
Am 18.10.2012 20:05, schrieb Matthew Miller:
On Thu, Oct 18, 2012 at 07:46:46PM +0200, Reindl Harald wrote:
and i am doing "tail -n 500 -f /var/log/messages" or whatever logfle i want to watch since years because i want to see what happened before, can scroll up and watch what is going on
This will work *right now* with journald, with almost identical semantics:
journalctl -n500 -f
(No space allowed after then -n.)
thats not the point
the point is that tail, grep, less, more, wathever-pager-you-use can be stucked with nearly any console-application in any creative way BUT the same way for all
if i want a pager - i use a pager
[root@srv-rhsoft:~]$ which systemctl alias systemctl='/bin/systemctl --no-pager --full' /bin/systemctl
sad that you need to use aliases to get the normal unix.behavior some tools like git doing not so is no excusion because this sounds like "i do it wrong because some others do too"
From: Reindl Harald h.reindl@thelounge.net Am 18.10.2012 20:05, schrieb Matthew Miller:
On Thu, Oct 18, 2012 at 07:46:46PM +0200, Reindl Harald wrote:
and i am doing "tail -n 500 -f /var/log/messages" or whatever logfle i want to watch since years because i want to see what happened before, can scroll up and watch what is going on
This will work *right now* with journald, with almost identical
semantics:
journalctl -n500 -f
(No space allowed after then -n.)
thats not the point
the point is that tail, grep, less, more, wathever-pager-you-use can be stucked with nearly any console-application in any creative way BUT the same way for all
if i want a pager - i use a pager
[root@srv-rhsoft:~]$ which systemctl alias systemctl='/bin/systemctl --no-pager --full' /bin/systemctl
sad that you need to use aliases to get the normal unix.behavior some tools like git doing not so is no excusion because this sounds like "i do it wrong because some others do too"
This is doomed to a flameware like vi vs emacs, I'm afraid. I love the auto-page feature, but agree the implementation might be more friendly. I like *nix traditions and pipelines -- I make some huge ones -- but systemctl and journalctl are user-interfaces, like git, man, info, etc. and I see nothing wrong with an implied pager. I think git has nailed the perfect combo where it allows configs of "always", "never" and "auto" (turns off paging, color, etc. for non-tty stdout).
-- John Florian
On Thu, 18.10.12 14:05, Matthew Miller (mattdm@fedoraproject.org) wrote:
journalctl -n500 -f
(No space allowed after then -n.)
The space thing is really annoying actually. glibc's getopt() insists on that for options such as "-n" that have an optional argument (i.e. which appear as "n::" in the opt string). I'd love to fix this if somebody has an idea to get getopt() to be nice to us here...
Lennart
On Thu, Oct 18, 2012 at 08:30:43PM +0200, Lennart Poettering wrote:
journalctl -n500 -f (No space allowed after then -n.)
The space thing is really annoying actually. glibc's getopt() insists on that for options such as "-n" that have an optional argument (i.e. which appear as "n::" in the opt string). I'd love to fix this if somebody has an idea to get getopt() to be nice to us here...
How about an option "--tail" (and maybe -t) which defaults to 10 (and turns off the pager?), and then making the value to -n be non-optional? This fits with the behavior of the tail command, where the number for n is also non-optional if n is given.
On Thu, Oct 18, 2012 at 8:30 PM, Lennart Poettering mzerqung@0pointer.de wrote:
On Thu, 18.10.12 14:05, Matthew Miller (mattdm@fedoraproject.org) wrote:
journalctl -n500 -f
(No space allowed after then -n.)
The space thing is really annoying actually. glibc's getopt() insists on that for options such as "-n" that have an optional argument (i.e. which appear as "n::" in the opt string). I'd love to fix this if somebody has an idea to get getopt() to be nice to us here...
Please just don't use optional arguments. http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html is the closest we have for a consensus on argument handling:
Guideline 7: Option-arguments should not be optional.
(The glibc behavior is also consistent with 12.1 item 2.) Mirek
Adam Williamson awilliam@redhat.com writes:
- don't auto-page;
yes; that's the best solution. The auto-pager is perhaps the most annoying feature of systemd. I have no problem in scrolling back some pages in my terminal with shift-pgup, but having a status request block (plain 'systemctl' or 'journalctl' request a status) is just broken.
I don't really look at it that way. Let's see, how to put it...
Okay, so with the old system, I don't recall *ever* doing 'cat /var/log/messages'.
It depends on the usecase. 'cat' is an option when system does not run for a long time yet or the different message types are filtered (e.g. into /var/log/secure). Else:
tail -n200 /var/log/messages
and when I see that information are too difficulty structured to find the wanted piece at the first glance:
<up> | less --> perhaps '-S' within less
This workflow is not possible with journalctl anymore.
It might not be the most efficient way to do things, but the '<up> | less' part works for a lot of other use cases too so that I do not have to remember which options are required by program A and which by program B to page the output.
Often, I know exactly what I want to do next after the 'tail -n200' (or a 'chkconfig --list') and start typing the next command while screen is filled with output. This does not work with systemd anymore because pager is entered.
Did/do you usually less /var/log/messages? Or did you usually cat it?
fwiw, I develop for embedded systems (which are using systemd). Showing complete log with 'journalctl' (and SYSTEMD_PAGER=) (and formerly 'cat /var/log/messages' or 'logread') is not uncommon in this usecase.
Or, do you want that e.g. the 'ls -l' output gets auto-paged?
Thinking about this case, when I'm doing an ls -l which I know will be long, I usually wind up trying to order it in such a way that what I want to see will be at the bottom (classically, ls -ltr)...that doesn't really work with journals. How about you?
filters like 'll -tr' or 'll -Sr' are efficient and not uncommon, indeed. But I use also the plain 'll' very often to get an overview.
But I never want 'll' to be auto-paged; regardless whether it displays 1 or 1000 lines.
Enrico
On Thu, Oct 18, 2012 at 10:35 AM, Enrico Scholz enrico.scholz@informatik.tu-chemnitz.de wrote:
Hence, the systemd tools should follow Unix/Linux tradition and specialize on their core functionality and avoid implementing "features" breaking user experience.
FWIW, it's not only implicit tradition: (info standards 'Program Behavior' 'User Interfaces') . Mirek