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

[Garance A Drosihn]

Apologies in advance for the length of this.  I seem to be in
"stream-of-consciousness" mode this week...
   - - - - -

>That does not get us matching POSIX/SUSv3, but it does get us a
>lot closer.  There are a few questions/issues that came up for me
>while writing this, but I'll list those in separate messages.  I'll
>also do a minimal update to the man page before commiting this.

Wrt "standards issues", the following things came up.  I made
arbitrary decisions on these things, and wanted to know what
other people felt.

With the new '-g pgidlist' option:  This is a standard option in
posix, and I never remembered using a -g option, and our man page
for `ps' does not mention one.  Much to my surprise, there already
was a -g option in the option-processing code of `ps':
	case 'g':
		break;			/* no-op */

A quick check of FreeBSD, NetBSD, and OpenBSD shows that everyone has
had this no-op option, going back to 1993/1994.  More amusing, SUSv3
writes:   "The -A option is equivalent to the BSD -g and the SVID -e.
            Because the two systems differed, a mnemonic compromise
            was selected."
So, what BSD had a `-g' option which behaved like `-A'?

In any case, I figured that if the option has been a no-op, and
undocumented for 10+ years, that it would be safe to just steal it.
I am going to assume this is okay, unless there is some strong
objection to it.
   - - - - -

The SUSv3 standard describes an option `-U userlist':
     Write information for processes whose real user ID numbers
     or login names are given in userlist
We already have a `-u`, and I even use it, so I wasn't going to
steal that!  However, I did want to have this ability, so I added
it as -R.  I will assume this seems reasonable.
   - - - - -

SUSv3 does not describe the option `-s sidlist', but many of the
other ps's that I work with have it, and I like having that ability.
I can imagine people screaming "creeping featurism!", but hey, I
was on a roll and it seemed like a pretty safe thing (standards-
wise) to add.  I *like* creeping features, as long as they don't
bloat the code too much...
   - - - - -

Indirectly related to that, I noticed that there was a flag named
KERN_PROC_SESSION defined for the kvm_getprocs() routine.  But when
I tried to use that flag, I get an error:
     ps: kvm_getprocs: No such file or directory

I do not have the time to look into this, so I guess I should write
up a PR for it.  (or is it not-supposed to work?).  It was easy to
avoid that by having the main() routine always do the selection
for '-s' processing.
   - - - - -

One of the things I puzzled over for awhile was how `-x' processing
should interact with all the "selector options".  I decided that
by default, all the options (except -p) should act like -x was
NOT specified.  By that I mean they will NOT match processes
which have no controlling terminal.  (it is a little confusing to
discuss this, due to all the double-and-triple negatives...).

That way, if the user does want to see those extra processes,
they can specify -x to see them, no matter what selectors were
specified.  If I did it the other way, then the user would need
yet another (new) option to indicate that they did NOT want to
see those processes.

I also reasoned that 'ps' (with no options) should behave the
same as 'ps -U myuserid'.  Prior to my updates, 'ps -U userid'
DID show the extra processes, but a plain 'ps' did not.  So,
what I have implemented is a slight change in behavior.  The
code in question had said:
	case 'U':
		uids = getuids(optarg, &nuids);
		xflg++;		/* XXX: intuitive? */
		break;

And I decided to answer that as "No".  This is a minor change
in behavior, but I'm hoping that in practice nobody will have
any problems due to this.  If they do, "just add -x"...
   - - - - -

Obviously the code for `-p pidlist' should show every process
it is told to, without caring if it has a controlling terminal.
The code used to do this by:
	case 'p':
		pid = atol(optarg);
		xflg = 1;
		break;
But that sets the "global xflg processing switch" for *all*
selector options given on the command, and I didn't think that
was right.  So I removed the xflg setting from there, but
changed the way the selection was done such that the pidlist
is matched before checking xflag.
   - - - - -

For `-U', there is a minor change in error-processing behavior
which should probably be done to match the standards, and to
match how other operating systems handle the same errors.  But
I did not make that change, because it was possible someone
cares about the behavior.  And that is:

If you specify multiple userids, and if any of those userids
are *invalid* (which is to say, there *is* no such username or
userid), then we presently print out a warning message and
ignore that one parameter.  We do not abort the command.  So
if you do:  ps -U root,gad,mail,baduser
you get a full 'ps' output with the warning message way at the
top of it.  When I tried this on other operating systems, they
all aborted the command with an error, and did not list any
processes.

That is what I would *like* to do with our `ps', but I could
imagine someone who was used to that behavior and depended on
it for some silly scripts or command-aliases that they have
written.  So, I left it as a warning -- but only for the `-U'
option.  For all other options, any value which would never
be valid is treated as a fatal error.

Would it be alright if I changed that to a fatal error, and
thus removed the ten lines of comments where I'm wringing my
hands in angst over making that change?
   - - - - -

My original intent was to MFC all of this to 4.x-stable before
4.10-release, but if I do that I will skip anything which is a
"new behavior".  I think that means it would be easier to skip
MFC-ing it at all (or at least wait until after 4.10-release).

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