PATCH for a more-POSIX `ps', and related adventures

[Garance A Drosihn]

At 9:54 PM -0500 3/24/04, Albert Cahalan wrote:
>On Wed, 2004-03-24, Garance A Drosihn wrote:
>
>>  >You've added both "A" and "-A", right? That is, you're still 
>>  >not using the presense/absense of a "-" to provide for separate
>>  >BSD and UNIX switch namespaces.
>>
>>  Apparently I have.  'ps A' and 'ps -A' seem to do the same
>>  thing for me.
>
>BTW, no real UNIX user ever uses -A. The -e option is used.
>The -A is a bit of crud some POSIX committee dreamed up.

We already have a -e, so I can't just add that.

It shouldn't hurt us to add -A, and it'll prevent me from
adding something else as -A at a later date...  :-)

>  > ... But my intention is to add the SUSv3-ish version of `-g'
>  > fairly soon.  ... Of the FreeBSD users who responded, the
>  > feeling has been "I'd rather have this SUSv3 option added
>  > than stick with the null-option".
>
>This is not a 2-way choice.
>
>1. null-option for a bit of SunOS 4 script compatibility
>2. SUSv3 "-g", plus accepting "g" alone as an alias
>3. SUSv3 "-g", plus "g" for SunOS 4 script compatibility
>
>If you choose #2 now, you'll have forever lost compatibility
>with SunOS 4.

I'll see what other FreeBSD'ers think about this.  I have
no SunOS 4 machines to worry about, and I have never used
"g" on Linux.  I'd rather make a clean break and just do
what the standard says.

>  > Note that we already have a `-u' option...  I notice that
>  > you're talking as if '-option' and 'option' are different
>  > namespaces.  This is not true on FreeBSD.  If we have a
>  > '-u', then we also have a 'u' which means the exact same
>  > thing.
>
>Yes, I know. This is why "ps -ef" won't work for you.
>AIX, Tru64, and Linux all split the namespaces to
>solve this problem. Join the crowd! :-)

Again.  This is a side-project I'm doing.  I can't afford to
devote a lot of time to `ps'.  If I try to split the namespace,
then the task of merely rewriting the man page will take more
time than I intend to spend on this.  ENOTIME.  (not right now,
at least).

I might hold off on `-g' for awhile to see if I find some time
to consider a namespace split.  I'm not too optimistic though.
Note that whatever the historical (BSD) background might be, our
man page actually describes all options as `-x', and not 'x'.

>  > >>      Adds a `-s sidlist' option, which is not in SUSv3,
>  > >>      but it is in solaris, linux, and irix ...
>  > >
>>  >What about the traditional BSD signals format? I know NetBSD
>>  >broke this... you too? It is valuable when debugging.
>>
>>  I don't know what you are referring to.  FreeBSD's `ps' did not
>>  have any `-s' option, so adding this option does not conflict
>>  with anything we presently have...
>>
>>  Hrm.  I see that NetBSD does have some `-s' option, although at
>>  least OpenBSD does not.  I forgot to check for that before.  I
>>  am still inclined to add the sidlist-s option to FreeBSD's `ps'.
>
>Wow. Real BSD is dead. The "s" option prints signal info.

I'll add the `-s' option for sidlist.  If we later split the
namespace, we can use a `s' option for signal info, if that is
appropriate.

>  > So, given a little time you might be able talk me into using
>>  environment vars to clean this up, but at the moment: ENOTIME...
>>
>>  We could perhaps tackle this for 6.x-branch (coming soon!), and
>>  then think about moving the result to `ps' in 5.x-stable if that
>>  result is reasonably backwards-compatible.
>
>You could always do this for the die-hards:

ENOTIME means ENOTIME.  It does not mean "tell me extra scripts
I could write on top of extra coding I could do".

>Got anything against long options? I use these:
>
>--Group      select by real group name or ID
>--User       select by real user name or ID
>--group      select by effective group name or ID
>--user       select by effective user name or ID

BSD commands rarely (almost never?) have long options.  I
personally don't mind them much, but, well, ENOTIME.

>Anyway, the "-X" or "X" idea is what??? You want to force
>enable the must-have-tty filter that "-x" or a SUSv3 option
>would disable? This is of very limited use I think.  What
>would happen with both X and x at the same time?

Like most "turn on" vs "turn off" options: the last one wins.

-- 
Garance Alistair Drosehn            =   gad at gilead.netel.rpi.edu
Senior Systems Programmer           or  gad at freebsd.org
Rensselaer Polytechnic Institute    or  drosih at rpi.edu