Re: Deprecating ps(1)s -w switch

On Tue, 25 Aug 2009 03:40:54 -0700 Brian Somers <brian@xxxxxxxxxxx> 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?). 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.

--
Brian Somers <brian@xxxxxxxxxxxx>
Don't _EVER_ lose your sense of humour ! <brian@xxxxxxxxxxx>

Attachment: signature.asc
Description: PGP signature

Relevant Pages

  • Re: Deprecating ps(1)s -w switch
    ... originator) challenged my reason for closing it. ... The suggestion is that ps's -w switch is a strange artifact that can ... back in the day terminals came in two widths... ... later some of the video terminals had a wide 132 mode you could switch to. ...
    (freebsd-hackers)
  • Deprecating ps(1)s -w switch
    ... originator) challenged my reason for closing it. ... The suggestion is that ps's -w switch is a strange artifact that can ...
    (freebsd-hackers)
  • support quality (Re: dump | restore fails: unknown tape header type 1853384566)
    ... The suggestion to eliminate the -a switch was particularly unhelpful -- and deserving of mockery. ... It is fairly obvious by now, that no real help will be forthcoming, for whatever reason. ...
    (freebsd-stable)
  • Re: BeginInvoke failing when executed in a form that was created in a worker thread...
    ... Suggestion 1: implement a producer/consumer algorithm. ... see if there is any valid reason to require all the events to ... Q, and thus when it creates an instance of FEventRaiser, FEventRaiser ... CMyClass), that internally makes use of FEventRaiser, on a worker ...
    (microsoft.public.dotnet.framework.windowsforms)
  • Re: BeginInvoke failing when executed in a form that was created in a worker thread...
    ... Suggestion 1: implement a producer/consumer algorithm. ... see if there is any valid reason to require all the events to ... Q, and thus when it creates an instance of FEventRaiser, FEventRaiser ... CMyClass), that internally makes use of FEventRaiser, on a worker ...
    (microsoft.public.dotnet.framework.windowsforms)
Loading