ps output line length (was: svn commit: r314685 - head/bin/ps)

Warner Losh imp at bsdimp.com
Sun Jan 28 17:25:50 UTC 2018


On Jan 28, 2018 9:51 AM, "Mike Karels" <mike at karels.net> wrote:

Recently, I was investigating an issue with top on -current while doing
a "make buildworld", and ran "ps axu|more" for comparison.  To my surprise,
I got only a few very long lines of output, containing full command lines
for compiler runs.  This quickly led me to the following commit, which
I unfortunately missed at the time, along with the following discussion:

> Author: cem
> Date: Sat Mar  4 22:38:10 2017
> New Revision: 314685
> URL: https://svnweb.freebsd.org/changeset/base/314685

> Log:
>   ps(1): Only detect terminal width if stdout is a tty
>
>   If stdout isn't a tty, use unlimited width output rather than
truncating to
>   79 characters.  This is helpful for shell scripts or e.g., 'ps | grep
foo'.
>
>   This hardcoded width has some history: In The Beginning of History[0],
the
>   width of ps was hardcoded as 80 bytes.  In 1985, Bloom@ added detection
>   using TIOCGWINSZ on stdin.[1]  In 1986, Kirk merged a change to check
>   stdout's window size instead.  In 1990, the fallback checks to stderr
and
>   stdin's TIOCGWINSZ were added by Marc@, with the commit message "new
>   version."[2]
>
>   OS X Darwin has a very similar modification to ps(1), which simply sets
>   UNLIMITED for all non-tty outputs.[3]  I've chosen to respect COLUMNS
>   instead of behaving identically to Darwin here, but I don't feel
strongly
>   about that.  We could match OS X for parity if that is desired.
>
>   [0]: https://svnweb.freebsd.org/csrg/bin/ps/ps.c?annotate=1065
>   [1]: https://svnweb.freebsd.org/csrg/bin/ps/ps.c?r1=18105&r2=18106
>   [2]:
>   https://svnweb.freebsd.org/csrg/bin/ps/ps.c?r1=40675&r2=
40674&pathrev=40675
>   [3]:
>   https://opensource.apple.com/source/adv_cmds/adv_cmds-168/
ps/ps.c.auto.html
>
>   PR:         217159
>   Reported by:        Deepak Nagaraj <n.deepak at gmail.com>

> Modified:
>   head/bin/ps/ps.c

> Modified: head/bin/ps/ps.c
> ============================================================
==================
> --- head/bin/ps/ps.c  Sat Mar  4 22:23:59 2017        (r314684)
> +++ head/bin/ps/ps.c  Sat Mar  4 22:38:10 2017        (r314685)
> @@ -194,6 +194,8 @@ main(int argc, char *argv[])
>
>       if ((cols = getenv("COLUMNS")) != NULL && *cols != '\0')
>               termwidth = atoi(cols);
> +     else if (!isatty(STDOUT_FILENO))
> +             termwidth = UNLIMITED;
>       else if ((ioctl(STDOUT_FILENO, TIOCGWINSZ, (char *)&ws) == -1 &&
>            ioctl(STDERR_FILENO, TIOCGWINSZ, (char *)&ws) == -1 &&
>            ioctl(STDIN_FILENO,  TIOCGWINSZ, (char *)&ws) == -1) ||

There were several following messages discussing this change, most notably
one by Bruce Evans
(https://docs.freebsd.org/cgi/getmsg.cgi?fetch=55022+0+
archive/2017/svn-src-head/20170312.svn-src-head).
I agree with his rational, and disagree with the change.  It seems to me
that the consensus was that the change was incorrect, although that might
just be my opinion.  However, I really think that the change needs to be
reverted.

The rationale for the original code was that, for interactive uses, the
output line length should be the same for "ps ...", "ps ...|more", and
"ps ... |grep".  The -w option exists to make the line longer; there is
no option to use the terminal size even if the output is redirected.
Hence, the tests for stderr or stdin being a tty.  This behavior has
been in place since 1990, as noted, and no substantial rationale has
been given for changing it other than "it doesn't matter if you use
less with side-to-side scrolling."  fwiw, I'm sure I discussed that
code with Marc at the time.

As was stated, scripts that want to use the full line should use -ww.
Interactive users have long been used to using -w when they need longer
output lines, e.g. to match patterns that don't occur within a screen's
width.

I propose reverting this change.


I tend to agree, but auxww is hard coded into my fingers.

Warner


More information about the svn-src-head mailing list