2 ms·
The need for separate configuration sounds contrived, breaks existing expected behavior, and assumes that this tool is special, unlike all of the other tools th
by 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 agoThanks 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?
- cardiffspaceman 12y agoASK HN: When did using open sores software become so much like joining the Communist Party?