From vadim@hostel.avtf.net  Tue Dec 20 15:48:04 2005
Return-Path: <vadim@hostel.avtf.net>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 540FB16A41F
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 20 Dec 2005 15:48:04 +0000 (GMT)
	(envelope-from vadim@hostel.avtf.net)
Received: from oasis.cctpu.edu.ru (oasis.cctpu.edu.ru [195.208.174.128])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 910B943D55
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 20 Dec 2005 15:48:01 +0000 (GMT)
	(envelope-from vadim@hostel.avtf.net)
Received: from hostel.avtf.net (hostel.avtf.net [82.117.64.190])
	by oasis.cctpu.edu.ru (8.11.3/8.11.3) with ESMTP id jBKFlig48782
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 20 Dec 2005 22:47:45 +0700 (KRAT)
	(envelope-from vadim@hostel.avtf.net)
Received: from hostel.avtf.net (localhost [127.0.0.1])
	by hostel.avtf.net (8.13.4/8.12.11) with ESMTP id jBKFlewR061040
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 20 Dec 2005 21:47:40 +0600 (NOVT)
	(envelope-from vadim@hostel.avtf.net)
Received: (from vadim@localhost)
	by hostel.avtf.net (8.13.4/8.12.11/Submit) id jBKFlelY061039;
	Tue, 20 Dec 2005 21:47:40 +0600 (NOVT)
	(envelope-from vadim)
Message-Id: <200512201547.jBKFlelY061039@hostel.avtf.net>
Date: Tue, 20 Dec 2005 21:47:40 +0600 (NOVT)
From: "Vadim S. Goncharov" <vadim_nuclight@mail.ru>
Reply-To: "Vadim S. Goncharov" <vadim_nuclight@mail.ru>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: ps(1) errorneously respects terminal column settings when output is not to a terminal
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         90690
>Category:       bin
>Synopsis:       [patch] ps(1) errorneously respects terminal column settings when output is not to a terminal
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Dec 20 15:50:02 GMT 2005
>Closed-Date:    
>Last-Modified:  Tue Aug 11 09:46:01 UTC 2009
>Originator:     Vadim S. Goncharov
>Release:        FreeBSD 4.11-STABLE i386
>Organization:
TPU AVTF Hostel
>Environment:
System: FreeBSD hostel.avtf.net 4.11-STABLE FreeBSD 4.11-STABLE #0: Tue Nov 22 00:07:38 NOVT 2005 vadim@hostel.avtf.net:/usr/obj/usr/src/sys/HOSTEL i386

>Description:
	Opposite to other bin utilities such as ls(1), ps(1) always respects terminal settings even if it's stdout is not a terminal (pipe, file). You should manually specify terminal settings ignorance to ps, but this behavior is counter-intuitive.
>How-To-Repeat:
	resize xterm window to small number of columns (i.e, 10) and try to do:
	ps aux | grep something
	you'll won't get anything matched even if you'll get it matched on a wider terminal
>Fix:
	Workaround is to add "ww" to ps cmd line args in every ps call pipelined or file redirected.
>Release-Note:
>Audit-Trail:

From: Oliver Fromme <olli@lurza.secnetix.de>
To: bug-followup@FreeBSD.org, vadim_nuclight@mail.ru
Cc:  
Subject: Re: bin/90690: ps(1) errorneously respects terminal column settings when output is not to a terminal
Date: Wed, 21 Dec 2005 18:00:06 +0100 (CET)

 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

From: Vadim Goncharov <vadim_nuclight@mail.ru>
To: bug-followup@FreeBSD.org
Cc: Oliver Fromme <olli@lurza.secnetix.de>
Subject: Re: bin/90690: ps(1) errorneously respects terminal column settings when output is not to a terminal
Date: Thu, 22 Dec 2005 05:26:00 +0600

 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
 

From: Oliver Fromme <olli@lurza.secnetix.de>
To: vadim_nuclight@mail.ru
Cc: bug-followup@FreeBSD.org
Subject: Re: bin/90690: ps(1) errorneously respects terminal column settings when output is not to a terminal
Date: Thu, 22 Dec 2005 14:41:53 +0100 (CET)

 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

From: Vadim Goncharov <vadim_nuclight@mail.ru>
To: Oliver Fromme <olli@lurza.secnetix.de>
Cc: bug-followup@FreeBSD.org
Subject: Re: bin/90690: ps(1) errorneously respects terminal column settings when output is not to a terminal
Date: Fri, 23 Dec 2005 05:52:31 +0600

 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
 

From: "Evan Clarke" <evan@proc.to>
To: bug-followup@FreeBSD.org, vadim_nuclight@mail.ru
Cc:  
Subject: RE: bin/90690: ps(1) errorneously respects terminal column settings when output is not to a terminal
Date: Sun, 1 Oct 2006 13:29:41 +1000

 ------=_Part_41535_20857243.1159673381993
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed
 Content-Transfer-Encoding: 7bit
 Content-Disposition: inline
 
 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
 
 ------=_Part_41535_20857243.1159673381993
 Content-Type: application/octet-stream; name=ps.wide-stdout.patch
 Content-Transfer-Encoding: base64
 X-Attachment-Id: f_esqvkdpa
 Content-Disposition: attachment; filename="ps.wide-stdout.patch"
 
 ZGlmZiAtYyBiaW4vcHMvcHMuMSBiaW4vcHMudy9wcy4xCioqKiBiaW4vcHMvcHMuMQlTdW4gU2Vw
 IDE3IDE3OjUwOjMwIDIwMDYKLS0tIGJpbi9wcy53L3BzLjEJRnJpIFNlcCAyMiAxMjowOToyNiAy
 MDA2CioqKioqKioqKioqKioqKgoqKiogMjM0LDI0MCAqKioqCiAgLkZsIHcKICBvcHRpb24gaXMg
 c3BlY2lmaWVkIG1vcmUgdGhhbiBvbmNlLAogIC5ObQohIHdpbGwgdXNlIGFzIG1hbnkgY29sdW1u
 cyBhcyBuZWNlc3Nhcnkgd2l0aG91dCByZWdhcmQgZm9yIHlvdXIgd2luZG93IHNpemUuCiAgLkl0
 IEZsIFgKICBXaGVuIGRpc3BsYXlpbmcgcHJvY2Vzc2VzIG1hdGNoZWQgYnkgb3RoZXIgb3B0aW9u
 cywgc2tpcCBhbnkgcHJvY2Vzc2VzCiAgd2hpY2ggZG8gbm90IGhhdmUgYSBjb250cm9sbGluZyB0
 ZXJtaW5hbC4KLS0tIDIzNCwyNDAgLS0tLQogIC5GbCB3CiAgb3B0aW9uIGlzIHNwZWNpZmllZCBt
 b3JlIHRoYW4gb25jZSwKICAuTm0KISB3aWxsIHVzZSBhcyBtYW55IGNvbHVtbnMgYXMgbmVjZXNz
 YXJ5IHdpdGhvdXQgcmVnYXJkIGZvciB5b3VyIHdpbmRvdyBzaXplLiAgVGhpcyBpcyB0aGUgZGVm
 YXVsdCBpZiBzdGRvdXQgaXMgbm90IGEgdHR5LgogIC5JdCBGbCBYCiAgV2hlbiBkaXNwbGF5aW5n
 IHByb2Nlc3NlcyBtYXRjaGVkIGJ5IG90aGVyIG9wdGlvbnMsIHNraXAgYW55IHByb2Nlc3Nlcwog
 IHdoaWNoIGRvIG5vdCBoYXZlIGEgY29udHJvbGxpbmcgdGVybWluYWwuCmRpZmYgLWMgYmluL3Bz
 L3BzLmMgYmluL3BzLncvcHMuYwoqKiogYmluL3BzL3BzLmMJU3VuIFNlcCAxNyAxNzozODozNSAy
 MDA2Ci0tLSBiaW4vcHMudy9wcy5jCUZyaSBTZXAgMjIgMTI6MDk6MzYgMjAwNgoqKioqKioqKioq
 KioqKioKKioqIDE5MSwxOTYgKioqKgotLS0gMTkxLDIwMCAtLS0tCiAgCWVsc2UKICAJCXRlcm13
 aWR0aCA9IHdzLndzX2NvbCAtIDE7CiAgCisgCS8qIFRlc3QgdG8gc2VlIGlmIHN0ZG91dCBpcyBu
 b3QgYSB0dHkuICovCisgCWlmICghaXNhdHR5KFNURE9VVF9GSUxFTk8pKQorIAkJdGVybXdpZHRo
 ID0gVU5MSU1JVEVEOwkKKyAKICAJLyoKICAJICogSGlkZSBhIG51bWJlciBvZiBvcHRpb24tcHJv
 Y2Vzc2luZyBrbHVkZ2VzIGluIGEgc2VwYXJhdGUgcm91dGluZSwKICAJICogdG8gc3VwcG9ydCBz
 b21lIGhpc3RvcmljYWwgQlNEIGJlaGF2aW9ycywgc3VjaCBhcyBgcHMgYXh1Jy4K
 ------=_Part_41535_20857243.1159673381993--
>Unformatted:
