From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4+) Gecko/20010921 Description of problem: Piping ps to less or to an output file results in lines greater then 80 chars being truncated, even when running in a window with greater then 80 lines of width. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.Start a maximized gnome-terminal 2.run ps e ps outputs chars to the edge of the screen 3.run ps e > ps.out output truncated at 80 chars Actual Results: ps output is truncated Expected Results: ps should output it's full, untruncated, line of information. Additional info:
This is a "historical" issue. Use the -w or w argument to make ps not cut the output.
It still doesn't seem like it does the "right" thing. When you have a terminal of 80 chars it should truncate to 80 chars. When you pipe the output somewhere it should give the full lines.
I guess the real point here is it's very strange to have an xterm with 130 columns when you do ps aux it fills the 130 columns but when you do ps aux | less it truncates to 80 columns.
Not truncating when the output is a pipe sounds reasonable. Reopening.
Is this fixed in procps-3.1.15?
Comments from upstream maintainer: Current behavior differs. There is no correct behavior though; the old behavior was quite reasonable. Failing to truncate lines makes "ps auxe | less" look ugly. Either way, this is a losing situation. Perhaps "ps" should link against curses so that TERM may be used. So not a bug.