So I have no dog in the systemd fight. However. $SYSTEMD_LESS is quite possibly one of the most aggressively stupid ways to force a bad UX on someone.
I mean seriously. If you have $LESS defined then you obviously have an expectation that less will behave in a certain way. An expectation that has in all probability built up over years of tweaking your shell.
For some other application to ignore that preference and in fact force it's own preference on you and only allow you to use your own preference for how less should work by reading not the docs for less but the docs for an unrelated application? That breaks so many rules it's just sad.
Yes it's easily fixable with a quick peek at the man page for systemd which might not be the first thing you check given you've been using less for years. Systemd's manpage is the last thing I would check. First would be what is my $LESS set to? Second would be is less still less? At some point it would occur to me that maybe systemd is being aggresively stupid and check their manpage.
But given I have no particular preference I would be inclined to assume it couldn't possibly be systemd's fault. I must have messed something up.
Put this minor annoyance in the middle of attempting to debug a segfaulting init? That's what we call a major annoyance.
I am not convinced that your less options that were (granted, you referred to the full environment) 'tweaked over the years' necessarily apply. When you defined those options you were thinking of all the cases where you invoke less, or at least where you knew less was being invoked.
Now journalctl defaults to use a pager if you invoke it. I'm not convinced that
journalctl
and
less /var/log/messages
should necessarily be configured the same. Maybe it would make sense to fall back to $LESS if $SYSTEMD_LESS isn't configured - I'm not sure - but I do think that it makes sense to have this environment variable.
>For some other application to ignore that preference and in fact force it's own preference on you and only allow you to use your own preference for how less should work by reading not the docs for less but the docs for an unrelated application? That breaks so many rules it's just sad.
Hmm.. Not in my world. The author was launching journalctl, not journalctl | less (which, as others have pointed out, would probably work as he expects it to). If you launch 'foo' and it doesn't do what you want and aren't an expert in all things 'foo', read man foo.
Which, for foo=journalctl, spells out that
- there is an option to stop truncating very long fields
- there is an option to use no pager
- the default pager is less
- the default less configuration is as quoted above
If you launch journalctl, see output you don't like and _don't_ skim the manual? Now that is what I personally would consider sad.
If you launch journalctl, see output you don't like and
_don't_ skim the manual? Now that is what I personally
would consider sad.
Yeah I'm afraid we have to agree to disagree here too. I'll just say that if you launch journalctl and see output that is obviously being printed to the screen by less my first thought will be to check my less configuration not journalctl's. These tools are meant to be used in a way that respects the users configurations for a reason.
Flouting that convention is bound to be rage inducing when encountered during a particularly nasty debugging session.
I think you and zaphar both have good points. That is to say, if for some reason you have $LESS set, it would be nice if journalctl respected it. (I'm trying not to take that and the kernel debug flag fiasco and view it as a trend.) However, as you say, if the only command you invoked was journalctl, it makes no sense to consult other documentation.
The need for separate configuration sounds contrived, breaks existing expected behavior, and assumes that this tool is special, unlike all of the other tools that call use a $PAGER. The comparison isn't "jornalctl" vs "less /var/log/messages". jornalctl should respect $PAGER (it does), and it should similarly respect any other environment variable the user sets.
If there really was a need to override behavior of the pager for just this one tool, the normal solution should be to locally override these cases:
alias journalctl="LESS='...opts...' journalctl"
It is worth pointing out that this solution works for any tool that uses the $PAGER, and isn't specific to journalctl. If, for some strange reason that isn't an acceptable solution (such as Lennart's hatred of shell scripting - which he's entitled to, if that's the way he wants HIS environment to work), then a far better solution would be, as you suggest, two variables in priority order. It's a trivial change: [pager.c:92]
This makes no assumptions about what the user intended and accepts either their general or specific settings, if present. This IS done for the $SYSTEMD_PAGER / $PAGER at [pager.c:59] making it somewhat strange that similar behavior wasn't also used for $LESS.
TL&DR: Setting defaults when $LESS isn't present is fine. Overriding behavior when a special, tool-specific request is also fine. Requiring everybody to search documentation and set a new environment variable to restore the standard, expected behavior is lazy and rude.
I set $LESS (and $PAGER, and $EDITOR, $VISUAL, $LESSOPEN, ...) for a reason, and the value(s) change depending on what I'm working on[1]. Overriding these should never be done as default behavior, or it is creating extra work for no reason. Assuming you know WHY I override $LESS (or any other environment variable) is always bad behavior, because you cannot know what all possible requirements that everybody will have.
// yet another reason I don't consider systemd to be usable
[1] I use custom tool that can push/pop environment variable overlays, which setup use/project specific behavior for a lot of stuff... including the pager.
Thanks a lot for the explanation and I appreciate your direct pointers to the source.
Now, given that we both consider the $SYSTEMD_LESS and $LESS cascadation (? You get what I mean) a decent idea and seeing that you found the right spot to add it, even gave a ~diff~ in your comment here...
Have you considered reporting that as a bug or sending that as a patch?
Wouldn't it make sense to defer judgement ("another reason I don't consider systemd to be usable") until your patch is accepted or rejected?
I mean seriously. If you have $LESS defined then you obviously have an expectation that less will behave in a certain way. An expectation that has in all probability built up over years of tweaking your shell.
For some other application to ignore that preference and in fact force it's own preference on you and only allow you to use your own preference for how less should work by reading not the docs for less but the docs for an unrelated application? That breaks so many rules it's just sad.
Yes it's easily fixable with a quick peek at the man page for systemd which might not be the first thing you check given you've been using less for years. Systemd's manpage is the last thing I would check. First would be what is my $LESS set to? Second would be is less still less? At some point it would occur to me that maybe systemd is being aggresively stupid and check their manpage.
But given I have no particular preference I would be inclined to assume it couldn't possibly be systemd's fault. I must have messed something up.
Put this minor annoyance in the middle of attempting to debug a segfaulting init? That's what we call a major annoyance.