16 ms·

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 s

by zaphar 12y ago

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.

darklajid 12y ago
We got to agree to disagree here, I guess. I think it makes sense to use a pager by default. 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.
- pdkl95 12y ago
  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] - less_opts = getenv("SYSTEMD_LESS"); + less_opts = getenv("SYSTEMD_LESS") || getenv("LESS"); 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 pager.c:92 http://cgit.freedesktop.org/systemd/systemd-stable/tree/src/shared/pager.c?h=v217-stable#n92 http://cgit.freedesktop.org/systemd/systemd-stable/tree/src/... pager.c:59 http://cgit.freedesktop.org/systemd/systemd-stable/tree/src/shared/pager.c?h=v217-stable#n59 http://cgit.freedesktop.org/systemd/systemd-stable/tree/src/... [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.
  - darklajid 12y ago

by zaphar 12y ago

darklajid 12y ago

We got to agree to disagree here, I guess. I think it makes sense to use a pager by default. 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.

pdkl95 12y ago
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] - less_opts = getenv("SYSTEMD_LESS"); + less_opts = getenv("SYSTEMD_LESS") || getenv("LESS"); 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 pager.c:92 http://cgit.freedesktop.org/systemd/systemd-stable/tree/src/shared/pager.c?h=v217-stable#n92 http://cgit.freedesktop.org/systemd/systemd-stable/tree/src/... pager.c:59 http://cgit.freedesktop.org/systemd/systemd-stable/tree/src/shared/pager.c?h=v217-stable#n59 http://cgit.freedesktop.org/systemd/systemd-stable/tree/src/... [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.
- darklajid 12y ago