Deprecating ps(1)s -w switch

Julian Elischer julian at elischer.org
Thu Aug 27 07:18:18 UTC 2009


Brian Somers wrote:
> On Tue, 25 Aug 2009 03:40:54 -0700 Brian Somers <brian at FreeBSD.org> wrote:
>> I recently closed bin/137647 and had second thoughts after Ivan (the
>> originator) challenged my reason for closing it.
>>
>> The suggestion is that ps's -w switch is a strange artifact that can
>> be safely deprecated.  ps goes to great lengths to implement width
>> limitations, and any time I've seen people not using -ww has either
>> been a mistake or doesn't matter.  Using 'cut -c1-N' is also a great
>> way of limiting widths if people really want that...
>>
>> I'd like to propose changing ps so that width limits are removed and
>> '-w' is deprecated - ignored for now with a note in the man page
>> saying that it will be removed in a future release.
>>
>> Does anyone have any objections to doing this?  I don't propose
>> merging this back into stable/8.
> 
> To clarify, my proposal is to silently ignore the -w switch (any/all of them)
> and to remove the code that reads the terminal width and truncates some
> columns based on the result (or based on "132").
> 
> The pros:
> 
> - ps's code becomes simpler.  It was mentioned that the ps code is
>   a minefield.  This would remove a few mines.
> - ps IMHO has no business knowing about terminal widths (and where
>   did the 132 column -w idea come from again?). 


back in the day terminals came in two widths... 80 and 132.
the teletype printers were 132 and the few video terminals there were
were 80.  later some of the video terminals had a wide 132 mode you 
could switch to.


  Some programs such
>   as iostat have similar (but way more broken) behaviour however whilst
>   others such as ls do not.
> - We remove the sizing bugs (only some columns are truncation victims).
> 
> The cons:
> 
> - people with visual expectations would have to learn to use less -S or some
>   similar tool.  This breaks POLA.
> - Scripts may exist that depend on the behaviour without -w.  Furthermore
>   having to handle ps from both before and after such a change in one
>   script can be painful.
> 
> It was also suggested that rather than changing the behaviour of one
> flavour of ps it would be better to adopt an approach more like linux's
> or even implementing POSIXs suggestions.  AFAIK the linux suggestion
> has been on the table for more time than I care to remember (wasn't
> Brett Glass going to provide a patch soon?).  Although I haven't read
> the linux code, I'm pretty sure it's a scary place - perhaps this is the
> reason that we don't have those patches yet.
> 
> 
> Unless others have more to say on the subject, I think it's clear that
> the most popular vote is to do nothing.  I think this is a shame as I
> find the pros more compelling than the cons, and I'm sure there are
> more than a few supporters out there on hackers@ that will stay
> silent.
> 



More information about the freebsd-hackers mailing list