Description of problem: See summary. Yes I am aware of 'if (!on_tty() || arg_no_pager) return;', and I am aware that 'git log' does the same thing. Regardless, please don't do this. Version-Release number of selected component (if applicable): systemd-units-26-2.fc15.x86_64 How reproducible: Always. Steps to Reproduce: 1. Run 'systemctl --all' at command line Actual results: Output gets piped automatically through 'less', and I get an extra forked process that I didn't ask for. Expected results: Output is sent to stdout in all cases, leaving me to manipulate it however I see fit. Additional info:
(In reply to comment #0) > Output gets piped automatically through 'less', and I get an extra forked > process that I didn't ask for. This is not a sufficient reason to change the current behaviour. Removing the feature would be a regression for the users who like it. You can set alias systemctl='systemctl --no-pager'
(In reply to comment #1) > This is not a sufficient reason to change the current behaviour. I would have assumed that eliminating cruft code dealing with (among other things) Debian-specific peculiarities regarding pagers would have been sufficient reason for the change. What ever happened to "do one thing and do it well"?
(In reply to comment #2) > I would have assumed that eliminating cruft code dealing with (among other > things) Debian-specific peculiarities regarding pagers would have been > sufficient reason for the change. There is ONE line of code that is specific to Debian and its derivatives. > What ever happened to "do one thing and do it well"? User-friendliness is one of the measures of doing things well.
(In reply to comment #3) > There is ONE line of code that is specific to Debian and its derivatives. ...and 50+ lines of code related to paging in general. > User-friendliness is one of the measures of doing things well. If I don't have a pager available, I am unable to get tty output without specifying --no-pager, or doing something horrible like piping through cat. Sorry, but this is inconsistent, and simply bad form.
> If I don't have a pager available, I am unable to get tty output without > specifying --no-pager, or doing something horrible like piping through cat. OK, that is a bug. Though unlikely to be seen in practice, because a Fedora system cannot boot without having util-linux (and thus /bin/more) installed.
(In reply to comment #5) > OK, that is a bug. Shall we re-open, or file a new bug? Ideally I'd like to see this bug re-opened, since the subject is still valid. The behaviour described above is just one symptom of ignoring UNIX programming convention and making assumptions about what your users want. Another symptom, for example, is that I get column headers if I let systemctl handle paging, but I don't if I decide to handle paging myself. Again: inconsistent. > Though unlikely to be seen in practice, because a Fedora > system cannot boot without having util-linux (and thus /bin/more) installed. True, but who knows where systemd might end up in future.
(In reply to comment #6) > (In reply to comment #5) > > OK, that is a bug. > > Shall we re-open, or file a new bug? I created bug 713707 for it.
(In reply to comment #6) > Another symptom, for example, is that I get column headers if I let systemctl > handle paging, but I don't if I decide to handle paging myself. Again: > inconsistent. The rationale is that when the output goes to a TTY, it's for the user to read, and the headers make it easier. When it goes somewhere else, it's likely for machine processing and the more raw format is suitable. Some people may not like it, but the decision was made a year ago and changing the behaviour now would surely be met with resistance from users who do like it. There is an inconsistency of a different kind that I can see: When not writing to a TTY, systemctl still shortens the unit names. I'd prefer it to apply '--full' in this case.
(In reply to comment #8) > The rationale is that when the output goes to a TTY, it's for the user to read, > and the headers make it easier. > When it goes somewhere else, it's likely for machine processing and the more > raw format is suitable. I'm sure you don't actually believe this - there are plenty of places output can go en route to the TTY. Again, it should be left to the user to decide what is "easier", not the programmer. As far as I can tell, there is no way to explicitly enable headers if the output is not a TTY. How does this make things "easier" if I want to pipe through 'watch' or 'egrep'? What if I am redirecting output to a file, or a printer? Output should be destination-neutral, and user controlled. > Some people may not like it, but the decision was made a year ago and changing > the behaviour now would surely be met with resistance from users who do like > it. To be honest, I don't have high expectations of things changing this late in the game (although I would love to be proved wrong!). However I think that this discussion needs to be had before more of this behaviour works its way into what will eventually be a core component of Fedora. > There is an inconsistency of a different kind that I can see: When not writing > to a TTY, systemctl still shortens the unit names. I'd prefer it to apply > '--full' in this case. Again, this should be up to the user. If you look to other commonly used commands for inspiration, then users will find it easier to pick up these new tools. Take a look at the behaviour of the 'w' flag of 'ps', for example.
I don't mind the default 'piping through pager' if output goes to tty. But the decision to remove the headers if output does not go to tty was really bad one.
I think the reasoning is the wrong way round on this one. If systemctl wants to behave differently it needs to give good reasons why. Please can the default be to follow standard Linux behaviour, with a configuration option to auto-page?
I changed systemctl upstream to always print the legend (the header and footer) by default, regardless of where stdout is going. '--no-legend' can be used to suppress it: http://cgit.freedesktop.org/systemd/commit/?id=ebed32bfe832071cde95f6adc01b1097ff079c90 Hopefully it's less confusing this way. The automatic pager by default is staying. Disable it if you want (export an empty 'SYSTEMD_PAGER=' environment variable or use the alias from comment #1). (In reply to comment #9) > > There is an inconsistency of a different kind that I can see: When not writing > > to a TTY, systemctl still shortens the unit names. I'd prefer it to apply > > '--full' in this case. > > Again, this should be up to the user. If you look to other commonly used > commands for inspiration, then users will find it easier to pick up these new > tools. Take a look at the behaviour of the 'w' flag of 'ps', for example. If you test 'ps aux | cat', you'll find that ps's output too depends on stdout type. It will automatically apply '-ww' when the output is not a tty.
systemd-37-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/systemd-37-1.fc16
*** Bug 768601 has been marked as a duplicate of this bug. ***
Sorry for accidentally duplicating this bug. I wholly concur with the traditionalists that auto-paging is a bug and should be fixed. "This is anathema to the UN*X way. We aren't running Windows here. We all know how to pipe to |less if we want a pager. What other sysadmin program goes through a pager by default?" Does ls auto-page? Does find force a pager on you? Did chkconfig --list? systemctl's list is pretty much a replacement for chkconfig --list and thus should behave similarly to what it's replacing. Any programmer that thinks that paging by default in UN*X is desired really doesn't understand the UN*X philosophy. What about consistency across programs? Doesn't that count for anything? Isn't that more confusing to newbie users, not less? To say we should auto-page for newbies would imply we should change everything, including ls, to auto-page. Isn't it hubris to think that one programmer's decision overrides that of generations of programmers who have thought about and already dismissed the hand-holding paradigm? Besides, newbies will almost exclusively use the GUI tools for systemctl once they become more mature, so why even attempt to throw away 40 years of UN*X philosophy to "help" them? So far the only argument I see here is "we made a mistake that will confuse people but now that we've made it it would confuse people to change it to make it unconfusing". That's not an argument. I'm not trying to flame, I would just like to see more dialog here. If/when other distros take up systemd, I would expect this discussion will pop up again and again. Since it is currently "a RH thing", we have the responsibility to make it right.
(In reply to comment #1) > Removing the feature would be a regression for the users who like it. You present another option: would one single user who "likes it" (who doesn't have a vested interest in the project) please reply and prove that someone indeed "likes it"? So far no one has.
Users who like it have no motivation to find this bugreport.
"Those who do not understand unix are forever doomed to reinvent it, poorly."
(In reply to comment #15) > I'm not trying to flame, I would just like to see more dialog here. I've tried to encourage dialogue regarding this behaviour on both bugzilla and the mailing lists; you can find the relevant bedtime reading at [1] and [2]. Unfortunately the discussion does tend to devolve into a flame-war, since: - Traditional UNIX programming concepts are simply outdated "purism", and by ignoring these conventions we are moving the platform boldly forward into the future - People[3] like systemd's default behaviour, since it makes things easier for them - This has been the systemd way from the beginning and it's too late to change things now anyway It looks like us naive traditionalists will simply just have to accept the new spirit of the age and get on with it - I'm only responding here because I think it's important to keep the dialogue open regardless of what happens with systemd. [1] http://lists.freedesktop.org/archives/systemd-devel/2011-June/002655.html [2] http://lists.fedoraproject.org/pipermail/devel/2011-June/152993.html [3] (citation needed)
Sorry I missed the discussion in June. I skipped F15 and sent straight from 14 to 16 so didn't hit this bug until recently. Interesting reading, those mailing lists. I saw I think 4-6 different people chime in on the "paging is bad" side, and rapidly scurry off when they felt like they were in the minority (bullied?). Obviously there is no convincing the other side at this time. I think time will prove us right on this one. If systemd moves to other distros and/or when it's in RHEL, I think we'll see a resurgence of this discussion. As soon as more people are exposed to it, those who understand why UN*X survived longer than any other OS in history will have their voices heard. If you're one of those voices, reading this, please post a quick "me too" as to why you think it's a bug and CC: yourself. Thanks!
Adding yourself to CC is fine, but posting "me too" comments without bringing any new insights is against Bugzilla etiquette.
Auto-paging a command line program is against UNIX etiquette. But we're in a new and progressive era, where existing mores don't matter anymore, remember? (Sorry, I really couldn't resist, I just couldn't...)
I completely agree with Trevor's comments, but here's something new to add to the discussion: How about the fact that a utility like systemctl is a critical system maintenance utility, while pagers are user-land optional extras, that may not even work reliably in a minimal boot/maintenance environment? Having systemctl go through a pager by default adds a critical dependency that shouldn't be there in the first place! There used to be a clear distinction between what belonged in /bin & /sbin vs what belonged in /usr/*bin, and things in the former group should never depend on those in the latter. This blurs that distinction in ways that could get nasty if the trend were to continue. For the love of all that is pure and clean in the UNIX/Linux world, please reopen this bug and fix it!
SystemD doesn't feel like a unix program. In addition to this invention, i.e. piping to a pager by default, it is also very noisy, instead of the single line of the requested information it displays a help page. It uses long program and command names, but does not define short, easy to type alternatives (see the svn command in subversion as an example how can it be done well). If they were in camel case I would think I am on Windows.
A nice compromise would be to allow an environment variable to stop it using the pager, without having to alter the command line. This results in no visible change unless elected, but is much "cleaner" than having a pile of aliases in your profile. Something like if SYSTEMDUSEPAGER is anything but null, act as if --no-pager was specified, else behave like it currently does.
(In reply to Paul "KK4DUY" Bransford from comment #25) $SYSTEMD_PAGER exists, has been mentioned here already in comment #12, and it is documented in man systemctl.
Totally idiotic behaviour. The whole of systemd is so annyingly stupid that it should be scrapped. For example, when restarting a daemon, the old way (/etc/init.d/server start), you'd get output to know if something went wrong (or if all was ok). When using systemd, I, as a system administrator, have run into the problem (multiple times) that I believe everything is ok after a restart because the idiotic systemd doesn't say anything. systemd restart server (annoying order of the arguments as well - the old way was better, just arrow up, and edit the last item on the line if you want to start something you just stopped, etc). systemd restart server doesn't say anything. To see what happens you have to run: systemd status server q (to get away from the unneeded less) systemd status server q systemd status server q and so on.. Totally idiotic behaviour. The need to add an environment variable or alias should be done by default by the distributions to fix this bug. To do this manually, on all machines is a lot of work for me..