From owner-svn-src-all@freebsd.org Mon Jan 29 19:46:41 2018 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 589BBEDAAA8; Mon, 29 Jan 2018 19:46:41 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [199.48.133.146]) by mx1.freebsd.org (Postfix) with ESMTP id DD32E82FA6; Mon, 29 Jan 2018 19:46:40 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from sweettea.beer.town (unknown [76.164.8.130]) by smtp.vangyzen.net (Postfix) with ESMTPSA id CCE9B5646E; Mon, 29 Jan 2018 13:46:39 -0600 (CST) Subject: Re: ps output line length (was: svn commit: r314685 - head/bin/ps) To: John Baldwin , mike@karels.net Cc: Conrad Meyer , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org References: <201801281622.w0SGMupF055172@mail.karels.net> <1737766.RPl9Duc0sC@ralph.baldwin.cx> From: Eric van Gyzen Message-ID: Date: Mon, 29 Jan 2018 13:46:35 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <1737766.RPl9Duc0sC@ralph.baldwin.cx> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jan 2018 19:46:41 -0000 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 >> >>> 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