Bug 626891 - systemctl produces unpredictable output based on terminal width
Summary: systemctl produces unpredictable output based on terminal width
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Lennart Poettering
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-08-24 16:28 UTC by Matthew Miller
Modified: 2010-09-15 12:00 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-09-15 12:00:08 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Matthew Miller 2010-08-24 16:28:18 UTC
I appreciate the attempt to fit the output of systemctl gracefully in a traditional terminal window, but this produces surprising results. If my window is 80 characters wide

  sudo systemctl list-units|grep CUPS

gets me nothing. If I make it 104 characters wide, I get output.

This will lead to user frustration and perhaps buggy scripts.

I think a better approach is to limit the amount of information displayed to 80 characters or less, and introduce flags which provide the fuller wide-output.


I also note that the help text at the bottom of the list-units command is not elegantly wrapped. I think it might be best to only show this if a --verbose flag is given. And it's probably better to put this at the *top* of the output, because in a long list, it's better for that to scroll off the page than the actual requested information.

Comment 1 Michal Schmidt 2010-08-24 16:55:40 UTC
You're right. systemctl list-units does a test for columns() even if the output is not a tty. This is a bug.

Comment 2 Matthew Miller 2010-08-24 17:52:36 UTC
There are two aspects, which perhaps should be split into two bugzilla entries:

1) the clear bug of testing for columns when the output is not a tty

2) the more "soft" case of cleaning up the user interface. There are cases where I am not able to make my terminal wider due to hardware or software limitations; I would still like to be able to get more or less detailed information. And there is the question of balance between verbose output and quick scanning for information once you know what you're doing.

Comment 3 Lennart Poettering 2010-08-24 18:52:36 UTC
We print additional output if you have a big terminal. That's a feature, not a bug. If you have no big terminal, or no terminal at all you won't see the Description column. But that's not a bug. It's just a feature that we show the description if you have a big terminal.

Note that the help text in the git version of systemd is actually wrapped < 80chs, so it should look pretty even then.

Comment 4 Matthew Miller 2010-08-24 19:14:58 UTC
(In reply to comment #3)
> We print additional output if you have a big terminal. That's a feature, not a
> bug. If you have no big terminal, or no terminal at all you won't see the
> Description column. But that's not a bug. It's just a feature that we show the
> description if you have a big terminal.

It is a bug that you can't see the description if you don't have a big terminal.

It is also a serious bug that you cannot process the description with commands like grep.

> Note that the help text in the git version of systemd is actually wrapped <
> 80chs, so it should look pretty even then.

Thank you -- that's much nicer. However, printing all of that help text every time is counterproductive. Please at least put it at the top of the message.

Comment 5 Lennart Poettering 2010-08-31 14:48:29 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > We print additional output if you have a big terminal. That's a feature, not a
> > bug. If you have no big terminal, or no terminal at all you won't see the
> > Description column. But that's not a bug. It's just a feature that we show the
> > description if you have a big terminal.
> 
> It is a bug that you can't see the description if you don't have a big
> terminal.

Well, if your terminal is just 80ch wide, then you cannot put more than 80ch on it. It's that simple. And that's not a bug. I am not sure what you want. Want me to come up with some magic powers that would allow me to put 120ch on a 80ch terminal? I am not sure I can do that for you. Sorry.

There's always "systemctl status" if you want to see full unit information.

And there's also --full which disables ellipsation and truncation of unit names and unit descriptions in the "list-units" output, which is much more useful in these cases.

> It is also a serious bug that you cannot process the description with commands
> like grep.

Well, we have "systemctl show -p Description foobar.service" for parsing in shell scripts. And that's documented.

> > Note that the help text in the git version of systemd is actually wrapped <
> > 80chs, so it should look pretty even then.
> 
> Thank you -- that's much nicer. However, printing all of that help text every
> time is counterproductive. Please at least put it at the top of the message.

I am not sure people would see it if we put it there. 

Anyway, I have now changed git upstream to generate the same output if you pipe things to a file or other non-tty regardless how big the terminal the process is attached to is. This should fix the bug.

Comment 6 Matthew Miller 2010-08-31 15:08:31 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > We print additional output if you have a big terminal. That's a feature, not a
> Well, if your terminal is just 80ch wide, then you cannot put more than 80ch on
> it. It's that simple. And that's not a bug. I am not sure what you want. Want
> me to come up with some magic powers that would allow me to put 120ch on a 80ch
> terminal? I am not sure I can do that for you. Sorry.

Hey. No need for that attitude.

If the terminal is more than 80ch wide, text can wrap. Or if I'm using less -S, I can scroll over.

What I'm asking for is flags that control the output in a deterministic fashion, so that I can always know what I will get. The `ps` command shows this in action -- it normally truncates to column width, but if you use the 'w' flag, it gives full output regardless.

And, if output isn't a terminal (say, you've passed it to less), it gives full-width output no matter what.


> > It is also a serious bug that you cannot process the description with commands
> > like grep.
> Well, we have "systemctl show -p Description foobar.service" for parsing in
> shell scripts. And that's documented.

Shell scripts aren't the only use case -- simply grepping output on the command line is another. It's really confusing and un-unix-like to have commands behave in this way.

> > > Note that the help text in the git version of systemd is actually wrapped > > > 80chs, so it should look pretty even then.
> > Thank you -- that's much nicer. However, printing all of that help text every
> > time is counterproductive. Please at least put it at the top of the message.
> I am not sure people would see it if we put it there. 

They can see it if they look, and they'll look if they need to know. Seriously: too much text! A flag to suppress it would be good, in any case.

> Anyway, I have now changed git upstream to generate the same output if you pipe
> things to a file or other non-tty regardless how big the terminal the process
> is attached to is. This should fix the bug.

Yes, that should fix less or grep or similar. Please do consider the other suggestions for improvement.

Comment 7 Lennart Poettering 2010-09-06 00:32:29 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > (In reply to comment #3)
> > > > We print additional output if you have a big terminal. That's a feature, not a
> > Well, if your terminal is just 80ch wide, then you cannot put more than 80ch on
> > it. It's that simple. And that's not a bug. I am not sure what you want. Want
> > me to come up with some magic powers that would allow me to put 120ch on a 80ch
> > terminal? I am not sure I can do that for you. Sorry.
> 
> Hey. No need for that attitude.

Sorry.

Opinions on https://bugs.freedesktop.org/show_bug.cgi?id=29916 ?

Comment 8 Zbigniew Jędrzejewski-Szmek 2010-09-06 18:38:52 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > (In reply to comment #4)
> > > > (In reply to comment #3)
> > > > > We print additional output if you have a big terminal. That's a feature, not a
> > > Well, if your terminal is just 80ch wide, then you cannot put more than 80ch on
> > > it. It's that simple. And that's not a bug. I am not sure what you want. Want
> > > me to come up with some magic powers that would allow me to put 120ch on a 80ch
> > > terminal? I am not sure I can do that for you. Sorry.
> > 
> > Hey. No need for that attitude.
> 
> Sorry.
> 
> Opinions on https://bugs.freedesktop.org/show_bug.cgi?id=29916 ?
The bug on freedesktop.org is a duplicate of this one.

Actually quite a lot of programs have the behaviour that they automatically create different output when run in a pipe: ls, dpkg, git blame.

Comment 9 Lennart Poettering 2010-09-14 11:52:18 UTC
Matthew, would it make sense to you to imply --full when output is not a tty?

PROS: grepping works much better when used on the output.

CONS: "systemctl | less" will look much less sexy

What says you?

Comment 10 Zbigniew Jędrzejewski-Szmek 2010-09-14 12:33:17 UTC
(In reply to comment #9)
> Matthew, would it make sense to you to imply --full when output is not a tty?
> 
> PROS: grepping works much better when used on the output.
> 
> CONS: "systemctl | less" will look much less sexy
It already does anyway: no color in less :(

Comment 11 Matthew Miller 2010-09-14 13:08:50 UTC
(In reply to comment #9)
> Matthew, would it make sense to you to imply --full when output is not a tty?

Yeah, that would definitely help.

> PROS: grepping works much better when used on the output.
> CONS: "systemctl | less" will look much less sexy

There could be a --forcesexy flag. Not really called that. :)

(In reply to comment #10)
> It already does anyway: no color in less :(

"-R" flag. Like this:

ls -l --color=always | less -R

Comment 12 Zbigniew Jędrzejewski-Szmek 2010-09-14 13:17:50 UTC
(In reply to comment #11)
> (In reply to comment #9)
> > Matthew, would it make sense to you to imply --full when output is not a tty?
> 
> Yeah, that would definitely help.
> 
> > PROS: grepping works much better when used on the output.
> > CONS: "systemctl | less" will look much less sexy
> 
> There could be a --forcesexy flag. Not really called that. :)
Maybe systemctl could get a flag like -p or --pager, which
would mean to call 'systemctl --color=always | $PAGER'
with PAGER=less -FSRX by default, like git does. 
Nobody will type a pipe sequence just to have color output :)

Comment 13 Lennart Poettering 2010-09-14 23:23:43 UTC
I am kinda tempted to say that more people will do "systemctl | less" than "systemctl | grep" on the normal command line, and hence the former should be the default and the latter need the option. Which would basically be the status quo: in the grep case you have to pass --full.

Comment 14 Matthew Miller 2010-09-15 00:03:58 UTC
(In reply to comment #13)
> I am kinda tempted to say that more people will do "systemctl | less" than
> "systemctl | grep" on the normal command line, and hence the former should be
> the default and the latter need the option. Which would basically be the status
> quo: in the grep case you have to pass --full.

This doesn't, however, match what other utilities do. It's expected for commands to turn off color and other fancy display features when passed to a pipe.

Comment 15 Lennart Poettering 2010-09-15 12:00:08 UTC
Well, turning off color is one thing that most pagers by default cannot deal with, and neither can grep really, and hence it is smart to disable it when piped. The ellipsation however is still nice to have in less, but not in grep.

Hence I think I'll leave the status quo here.

I do like Zbyszek's git-style pager invocation idea. Added this now to my todo list. Zbyszek, patches very welcome for this! ;-)

Anyway, I believe the main issue originally raised is fixed already, so I am closing this bug now. Thanks for all your input!


Note You need to log in before you can comment on or make changes to this bug.