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

[Garance A Drosihn]

At 4:52 PM -0500 3/24/04, Albert Cahalan wrote:
>Wow, the SUSv3 ps problem is finally being addressed.

Eek!  Someone taking me way too seriously!    :-)

>I hope that you'll be willing to discuss this with the Linux
>ps author (me)  and maybe drag in a few other ps authors or
>maintainers.

I very much like the goal, but (as usual) I'm a bit pressed for
time.  As I said in my original message, all I really *needed* to
do was to get rid of the one case where `ps' started printing an
error message on freebsd-current, where it had not been printed
on freebsd-stable (4.x).

>Perhaps there is a better place to discuss this. I'm not even
>sure my mail will get through to freebsd-arch and
>freebsd-standards.

I have trimmed freebsd-arch.  We don't need to discuss it on
two freebsd mailing lists.

>I think you may be painting yourself into a corner if you commit
>the proposed changes. Please delay them at the very least. I'd
>be happy to work with somebody to write a spec for good behavior,
>kind of like SUSv3 plus BSD minus crufty bits.

We (FreeBSD) are just about to start calling our 5.x branch the
"stable" branch.  As such, I am not comfortable with removing
any of the "crufty bits".  I don't want to paint `ps' further
into a corner than it already is, but I simply do not have the
time right now to address all `ps' vs SUSv3 issues.  No matter
how nice it would be -- ENOTIME.

>------ comments on various proposed changes ------
>  >      Adds the -A option of SUSv3 (exactly the same as `-ax')
>
>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.

>  >      Adds the `-G gidlist' and '-g pgidlist' options of SYSv3.
>>            (note that this replaced a null `-g' option...)
>
>Eh... must you? You're trashing compatibility with SunOS 4.
>Separate option namespaces solve this problem fairly well,
>especially if you let an environment variable force the
>parser into a pure traditional-bsd mode.

My initial commit (which I still hope to do this weekend) will
leave `-g' as it is (ie, as a null option).  But my intention
is to add the SUSv3-ish version of `-g' fairly soon.  Since
none of the BSD's have ever documented this option, I don't
feel as bad about stealing it to line up with SUSv3.  Of the
FreeBSD users who responded, the feeling has been "I'd rather
have this SUSv3 option added than stick with the null-option".

>  >      Adds a `-R ruserlist' option, which is the same as what
>>            SYSv3 describes for `-u' (we already have a `-u').
>>            Amazingly, none of solaris, linux, or irix seem to
>>            have any kind of `-R' option.
>
>Why should they? The -u option works fine.

I meant that as: "No one uses -R for something else, so I can
use it for this".  Given an infinite number of possible options,
and multiple programmers working on separate versions of `ps',
it's amazing that there's any single-letters left over!  :-)

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.

>  >      Adds a `-s sidlist' option, which is not in SUSv3, but
>>            it is in solaris, linux, and irix -- and it's an
>>            option I have personally wished for on occasion...
>
>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'.

>  >      Better parsing of options.  Better error messages for
>>            invalid values (IMO).
>
>I notice that you're jumping through hoops for "ps t" support.
>Getting rid of the getopt-based parser would greatly help you.

ENOTIME.  `ps' is not high on my own personal priority list.
(given that my real-world job has nothing to do with FreeBSD,
and that job is about to get very busy again).

(I don't get your example of `ps -t' here.  Iirc that processing
is pretty straightforward.  But some of the other option-handling
does do a bit of hoop-jumping, so I know what you're getting at)

>  >      Applies all these selection criteria *before* sorting
>>            the list of processes we get from kvm_getprocs(),
>>            and before using the list to compute the sizes of
>>            the output fields.
>
>Cute, but memory-intensive and not friendly if your process
>table ever gets corrupted. It's not so nice on SMP either,
>since a grep or awk script ("ps ... | awk ...") can't start
>until ps is done.

???  How can it be memory intensive if I *avoid* sorting the
entire list of processes?  I already *have* the entire list,
it's just a question of how many of the elements I sort.  I
can't possibly be doing more work or using more memory than
the previous code did.  Well, at least not for this part...

>  > I am not thrilled with that idea, but at the moment I can't
>  > think of a better one.  I *would* like to support matches of
>  > both real and effective users.  I guess we could add some
>  > other option which would say "use the POSIX definitions of
>  > -u and -U", but that doesn't exactly thrill me either.
>
>Why not? Tru64 uses the CMD_ENV environment variable to
>handle this. Linux does too, with PS_PERSONALITY taking
>priority. So, on either OS, you can do:

I don't like keying a command's option-parsing behavior off of
environment variables.  I can be talked into it if it would be
following some precedent in other OS's, but my initial-reaction
to this tactic (for any command) is to avoid it.  Please note that
this isn't some multi-month project that I've been working on, I
have been looking at this for less than a week, and very little
of that week.  I just thought I'd do some of the "easy stuff"
that would get our `ps' a little closer to SUSv3.

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.

>  > ....  If I do this, I'll add a -X option which would "turn off
>  > -x", so to speak.  There are times where I don't want to see
>  > the extra processes.  A -X' option does not seem to conflict
>  > with solaris, aix, or irix.  Linux does have a -X, but it's
>  > for "old Linux i386 register format", and I think we can safely
>  > assume we would never implement that, and that it is also not
>  > likely to become a "standard" option...
>
>The X format is not really i386-specific. The column headers
>sure look like it, but the ESP and EIP columns are really just
>the stack and instruction pointers. They work fine on PowerPC.

I wasn't looking at "i386", I was looking at "old ... format",
which is how it is described in the redhat 7.3 man page. I
assumed that meant "This is only provided for some old things,
we don't expect people to use it for new stuff".

>You're not helping the suffering sysadmins if you add yet
>another incompatible feature. Portable scripts won't be able
>to use your proposed X option.

If all the work I'm doing here does not *help* any sysadmins, I
would be mighty surprised.  Linux is the only OS that I noticed
using -X.  If you're happily handling multiple name-spaces for
options, then I'm not sure why -X is going to be so much weirder
than our already-existing -x.

-- 
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