Re: ps output line length (was: svn commit: r314685 - head/bin/ps)
On 28 Jan 2018, at 11:22, Mike Karels wrote: > 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 have several scripts which work on the output of 'ps', and none of my scripts would have noticed this change because they include -ww and they also set 'local COLUMNS=180' and export the value of COLUMNS. It also looks like the change from March 2017 is only in -current, and has not been MFC-ed into 11.x-stable. So reverting the change seems reasonable to me. I will note that the behavior of 'ps' on linux seems to match what the change does. If you 'ps axu' the output is the width of your terminal, and if you 'ps axu | grep something' then the output width seems to be infinity (or at least it's somewhere over 2500 characters). I have not checked how 'ps' acts on the other BSD's. -- Garance Alistair Drosehn= dro...@rpi.edu Senior Systems Programmer or g...@freebsd.org Rensselaer Polytechnic Institute; Troy, NY; USA ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: ps output line length (was: svn commit: r314685 - head/bin/ps)
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=18106 >>> [2]: >>> >>> https://svnweb.freebsd.org/csrg/bin/ps/ps.c?r1=40675=40674=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.cSat Mar 4 22:23:59 2017(r314684) >>> +++ head/bin/ps/ps.cSat 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 *)) == -1 && >>> ioctl(STDERR_FILENO, TIOCGWINSZ, (char *)) == -1 && >>> ioctl(STDIN_FILENO, TIOCGWINSZ, (char *)) == -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 ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: ps output line length (was: svn commit: r314685 - head/bin/ps)
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=18106 > > [2]: > > > > https://svnweb.freebsd.org/csrg/bin/ps/ps.c?r1=40675=40674=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.cSat Mar 4 22:23:59 2017(r314684) > > +++ head/bin/ps/ps.cSat 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 *)) == -1 && > > ioctl(STDERR_FILENO, TIOCGWINSZ, (char *)) == -1 && > > ioctl(STDIN_FILENO, TIOCGWINSZ, (char *)) == -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'. -- John Baldwin ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: ps output line length (was: svn commit: r314685 - head/bin/ps)
On Jan 28, 2018 9:51 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=18106 > [2]: > https://svnweb.freebsd.org/csrg/bin/ps/ps.c?r1=40675= 40674=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 *)) == -1 && >ioctl(STDERR_FILENO, TIOCGWINSZ, (char *)) == -1 && >ioctl(STDIN_FILENO, TIOCGWINSZ, (char *)) == -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 ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
ps output line length (was: svn commit: r314685 - head/bin/ps)
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=18106 > [2]: > https://svnweb.freebsd.org/csrg/bin/ps/ps.c?r1=40675=40674=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 *)) == -1 && >ioctl(STDERR_FILENO, TIOCGWINSZ, (char *)) == -1 && >ioctl(STDIN_FILENO, TIOCGWINSZ, (char *)) == -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. Mike ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"