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

Eric van Gyzen eric at vangyzen.net
Mon Jan 29 19:46:41 UTC 2018


On 01/29/2018 12:08, John Baldwin wrote:
> On Sunday, January 28, 2018 10:22:56 AM Mike Karels 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 do feel like I've always assumed I needed -ww if I wanted long lines to
> be deterministic.  This feels like it breaks interactive 'ps | grep foo'
> on a desktop with lots of long command lines (e.g. with KDE or the like)
> as you lose the single-line output of the original interactive 'ps'.

In case this thread needs another "me too":  me too.

Eric


More information about the svn-src-head mailing list