bin/90690: ps(1) errorneously respects terminal column settings when output is not to a terminal

Vadim Goncharov vadim_nuclight at mail.ru
Thu Dec 22 16:00:26 PST 2005


The following reply was made to PR bin/90690; it has been noted by GNATS.

From: Vadim Goncharov <vadim_nuclight at mail.ru>
To: Oliver Fromme <olli at lurza.secnetix.de>
Cc: bug-followup at FreeBSD.org
Subject: Re: bin/90690: ps(1) errorneously respects terminal column settings when output is not to a terminal
Date: Fri, 23 Dec 2005 05:52:31 +0600

 Hello Oliver,
 
 Thursday, December 22, 2005, 7:41:53 PM, you wrote:
 
  >> OF> What you describe is standard BSD ps(1) behaviour, as is
  >> OF> documented in the manual page.
  >> 
  >> It's not clarified there in the case of redirection.
 
 OF> Redirection of stdout does not change the behaviour of ps,
 OF> so it need not be mentioned.  Almost all tools in the base
 OF> system don't care what their stdout is, and there is no
 OF> reason to document that fact in all of the manual pages.
 
 Because these tools (almost all of base system) don't care about
 terminal at all, always assuming "dumb wide printer" stdout. For
 example, try "df -i" - you'll get garbled output on standard 80-column
 terminal with wrapped lines. Because they're always care about
 redirection giving full output, and not your terminal.
 
 OF> Note that ls(1) is an exception, not ps(1).  That's why it
 OF> is documented in the ls manpage.
 
 What about top(1) ?
 
  >> OF> Basically, the intent is that, when you redirect ps(1) output
  >> OF> somewhere (to a file or pipe), you get exactly the same that
  >> OF> is displayed on the screen.
  >> 
  >> This is counter-intuitive.
 
 OF> For me, it is intuitive.  When I type "ps" in the shell,
 OF> look at the output and then decided to use grep, I expect
 OF> it to work on the same kind of data.
 
 Yeap, but I expect work on _full_ data, as with all other tools not
 respecting terminal.
 
 OF> In my opinion, tools that behave differently depending on
 OF> their stdout are counter-intuitive.
 
 If so, all tools which at least see at what stdout is (terminal or not)
 are breaking unix-way because they must simply stream data out, not
 preparing it for terminal at all.
 
  >> If I am redirecting output to file, I expect
  >> to see result somewhat later. It's somewhat strange that result will be
  >> not stable constant, but unpredictable, depending on terminal settings
  >> at the moment of running.
 
 OF> As I pointed out, that's the reason why the -ww options
 OF> exist.  You cannot change that without breaking existing
 OF> scripts.  And without breaking existing admins.  ;-)
 
 What existing scripts and admins would break situation of not needing to
 add -ww to cmd line in case of redirect? Any real facts?
 
  >> Yes, but grep is not the only thing used with redirection. Moreover,
  >> I've tried to run "ps aux > myprocs.txt" on Linux (Slackware 10) and it
  >> worked as I expected - full lines in file while on terminal they were
  >> truncated (and linux have pgrep(1) also).
 
 OF> The ps of Linux behaves differently because it's a different
 OF> ps.  Historically, there are two different families of ps
 OF> implementations:  SysV and BSD.  Both are incompatible and
 OF> have different options.  Linux chose to adapt the SysV
 OF> behaviour, with some compatibility hacks for BSD.  You'll
 OF> notice the "bad syntax" warning when you type "ps -aux".
 OF> Therefore you cannot take Linux' ps for comparison.
 
 I can, because stdout problem is absolutely unrelated to other
 implementation functionality.
 
  >> So, I insist that ps(1) behavior should be corrected. OK, developers may
  >> have another opinion, but in that case at least ps man page should be
  >> fixed, adding a paragraph clarifying this, somewhat like what you
  >> explained earlier in this post.
 
 OF> Personally I think that the manpage explains the behaviour
 OF> sufficiently.  But adding a little clarification probably
 OF> won't hurt.  Especially beginners often forget to use -ww
 OF> in scripts.
 
 Yes, I preferably meant beginners at first when did send-pr.
 
 OF> For example, a sentence could be added to the paragraph at
 OF> the beginning which explains the default output format:
 OF> "Note that the command is truncated to the terminal width;
 OF> see the -w option to change that."
 
 No, this is too short. It should be more detailed one- or two-paragraph
 explanation, like the one you gave in your first response to PR.
 
 -- 
   WBR, Vadim Goncharov 
 FidoNet 2:5005/106.426  ICQ#166852181  mailto:vadim_nuclight at mail.ru
 


More information about the freebsd-bugs mailing list