What you describe is standard BSD ps(1) behaviour, as is
documented in the manual page.

Basically, the intent is that, when you redirect ps(1) output
somewhere (to a file or pipe), you get exactly the same that
is displayed on the screen.

The rules are:  If ps(1) is running in a terminal, it's width
is used.  If it's not running in a terminal (e.g. via a cron
job) or the width cannot be determined, the default is 80
columns.  To determine the terminal width, any one of stdout,
stderr or stdin is used -- therefore, to let ps(1) ignore the
terminal width, you have to redirect stderr and stdin.

If you specify the -w option once, the limit is expanded to
132 columns (unless your terminal width is already larger
than that).  Finally, if you specify -w twice, the width is
assumed to be unlimited.

When you use ps(1) in a pipe to grep for things, you should
always use the -ww options.  Also note that newer versions
of FreeBSD (> 4.x) have a pgrep(1) command which can be used
as a convenient replacement for ps | grep pipes.

Best regards
   Oliver

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

I suggested holding a "Python Object Oriented Programming Seminar",
but the acronym was unpopular.
        -- Joseph Strout

Hello Oliver,

Wednesday, December 21, 2005, 11:00:06 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> 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. 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> The rules are:  If ps(1) is running in a terminal, it's width
OF> is used.  If it's not running in a terminal (e.g. via a cron
OF> job) or the width cannot be determined, the default is 80
OF> columns.  To determine the terminal width, any one of stdout,
OF> stderr or stdin is used -- therefore, to let ps(1) ignore the
OF> terminal width, you have to redirect stderr and stdin.
OF> If you specify the -w option once, the limit is expanded to
OF> 132 columns (unless your terminal width is already larger
OF> than that).  Finally, if you specify -w twice, the width is
OF> assumed to be unlimited.

Compare it with ls(1) behavior. If output is not to a terminal, ls
behaves as expected, not using any terminal crap. And this is clearly
documented in ls man page.

OF> When you use ps(1) in a pipe to grep for things, you should
OF> always use the -ww options.  Also note that newer versions
of FreeBSD (>> 4.x) have a pgrep(1) command which can be used
OF> as a convenient replacement for ps | grep pipes.

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).

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.

-- 
  WBR, Vadim Goncharov 
FidoNet 2:5005/106.426  ICQ#166852181

Vadim Goncharov wrote:
 > Oliver Fromme 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.

Redirection of stdout does not change the behaviour of ps,
so it need not be mentioned.  Almost all tools in the base
system don't care what their stdout is, and there is no
reason to document that fact in all of the manual pages.

Note that ls(1) is an exception, not ps(1).  That's why it
is documented in the ls manpage.

 > 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.

For me, it is intuitive.  When I type "ps" in the shell,
look at the output and then decided to use grep, I expect
it to work on the same kind of data.

In my opinion, tools that behave differently depending on
their stdout are counter-intuitive.

 > 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.

As I pointed out, that's the reason why the -ww options
exist.  You cannot change that without breaking existing
scripts.  And without breaking existing admins.  ;-)

 > OF> The rules are:  If ps(1) is running in a terminal, it's width
 > OF> is used.  If it's not running in a terminal (e.g. via a cron
 > OF> job) or the width cannot be determined, the default is 80
 > OF> columns.  To determine the terminal width, any one of stdout,
 > OF> stderr or stdin is used -- therefore, to let ps(1) ignore the
 > OF> terminal width, you have to redirect stderr and stdin.
 > OF> If you specify the -w option once, the limit is expanded to
 > OF> 132 columns (unless your terminal width is already larger
 > OF> than that).  Finally, if you specify -w twice, the width is
 > OF> assumed to be unlimited.
 > 
 > Compare it with ls(1) behavior. If output is not to a terminal, ls
 > behaves as expected, not using any terminal crap.

Unless you specify -C.  However, if you ask me, the
behaviour of ls(1) is counter-intuitive and should be
fixed.  Problem is that it would break existing scripts
(and admins) and violate SUSv3/POSIX2001.

 > OF> When you use ps(1) in a pipe to grep for things, you should
 > OF> always use the -ww options.  Also note that newer versions
 > of FreeBSD (>> 4.x) have a pgrep(1) command which can be used
 > OF> as a convenient replacement for ps | grep pipes.
 > 
 > 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).

The ps of Linux behaves differently because it's a different
ps.  Historically, there are two different families of ps
implementations:  SysV and BSD.  Both are incompatible and
have different options.  Linux chose to adapt the SysV
behaviour, with some compatibility hacks for BSD.  You'll
notice the "bad syntax" warning when you type "ps -aux".
Therefore you cannot take Linux' ps for comparison.

 > 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.

Personally I think that the manpage explains the behaviour
sufficiently.  But adding a little clarification probably
won't hurt.  Especially beginners often forget to use -ww
in scripts.

For example, a sentence could be added to the paragraph at
the beginning which explains the default output format:
"Note that the command is truncated to the terminal width;
see the -w option to change that."

Best regards
   Oliver

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

"One of the main causes of the fall of the Roman Empire was that,
lacking zero, they had no way to indicate successful termination
of their C programs."
        -- Robert Firth

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@mail.ru

My thoughts on issue:

I cannot think of an example where including more information on the
*same line * will break any scripts.

Attached low-impact patch to implement "correct" behaviour.

cd /usr/src
patch < ps.wide-stdout.patch

Comment 6 Eitan Adler 2017-12-31 07:58:36 UTC

For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped

Comment 7 Alex Kozlov 2018-02-18 07:22:15 UTC

Fixed in 2017 (r314685) in FreeBSD 12. See also Bug 217159.