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):
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
This is a "historical" issue. Use the -w or w argument to make ps not cut the
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
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
Not truncating when the output is a pipe sounds reasonable.
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.