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

[Albert Cahalan]

On Wed, 2004-03-24 at 19:43, Garance A Drosihn wrote:
> 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

I've been thinking about getting at least the Tru64 and AIX
sort of behavior into the next UNIX standard. I showed up a
bit too late for the last revision.

> >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'll trust that you know better than I do, but "arch"
sure sounds like an appropriate place.

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

That got mis-parsed. SUSv3 has some crufty bits that
are often violated. You can keep your own crufty bits.

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

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.

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

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. (and thus with Linux, though "g" isn't a
requirement for Linux scripts) It would be quite a bit of
trouble to switch from behavior #2 to #3 after people have
gotten used to behavior #2.

> >  >      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!  :-)

Oh. In that case, "-R" is used to select by PRM groups.
It's an HP/UX feature that Linux is likely to adopt.
Plain "R" (no hyphen) will remain available of course.

> 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! :-)

With a trivial shell script in /usr/local/bin, Solaris
works this way too. Everybody has the script, right?

#!/bin/sh
case "$1" in
    -*)
        exec /bin/ps "$@"
        ;;
    *)
        exec /usr/ucb/ps "$@"
        ;;
esac

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

Wow. Real BSD is dead. The "s" option prints signal info.
At least Tru64 and AIX still support this. NetBSD had it
until they added an extra 96 signals. With a bit of whitespace
deleted, my implementation gives:

UID  PID   PENDING   BLOCKED   IGNORED    CAUGHT STAT TTY     TIME COMMAND     
123 1866  00000000  00010000 <00380004  00010002 S    tty1    0:00 /bin/sh     
123 2042  00000000  00000000 <00000000  00003207 S    tty1    0:00 xinit /     
123 2046  00000000  00000000 <00000000  000014c0 S    tty1    0:00 x-sessi     
123 9149  00000000  00000000 <00384004  4b813efb S    pts/1   0:00 bash      

Wide output gives all 64 signals, instead of the "<" or " ".

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

If you're already reading the whole thing before printing
any output, then sure. GNU Hurd does this too. It makes
for pretty output, but it doesn't scale.

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

You could always do this for the die-hards:

#!/bin/sh
# This is the /usr/ucb/ps script.
CMD_ENV=bsd exec /bin/ps "$@"

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

I can't support your proposed "ps X" (or "ps -X") in the default
personality for my ps. Any "portable" (free OS for now) script
using this would need to set CMD_ENV=bsd or PS_PERSONALITY=bsd.

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

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?