Date: 24 Mar 2004 16:52:52 -0500 From: Albert Cahalan <albert@users.sf.net> To: freebsd-arch@freebsd.org, freebsd-standards@freebsd.org Cc: des@des.no Subject: Re: PATCH for a more-POSIX `ps', and related adventures Message-ID: <1080165171.2232.910.camel@cube>
next in thread | raw e-mail | index | archive | help
Wow, the SUSv3 ps problem is finally being addressed. 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. This is
your chance to put an end to sysadmins everywhere cursing the
historical ps differences; don't let NIH stop you.
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'm a Comcast customer. :-/
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.
------ comments on various proposed changes ------
> Now, after about 30 consecutive "as long as I was there" small
> projects, I have an update which:
> Changes -p so it accepts a list of process IDs, and -t so
> it accepts a list of terminal names (instead of only
> allowing a single value).
Good.
> 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. You wouldn't be caving to the
Linux world if you did; I swiped the idea from Digital UNIX.
(a.k.a. Tru64 or OSF/1) It's also in AIX.
> 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.
> 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.
Linux is a bit special here, in that -u may be used simultaneously
with the BSD-style u option: ps u -u root,albert
> 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.
> Allows the user to specify any of these "selector options"
> multiple times, and have it keep adding to that
> list instead of replacing values for that list.
Good.
> 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.
> Fixes interactions between all these "selector options",
> & our `-x' option (which is not mentioned in SUSv3).
> For the selector options, I tried to meet the
> description of: "If any are specified, the default
> list shall be ignored and ps shall select the
> processes represented by the inclusive OR of all
> the selection-criteria options."
Here you have a big ugly problem. Historical BSD selection
acts by lifting filters which are enabled by default.
UNIX selection acts by adding processes to a set that will
be displayed, except that the default is a special case
to avoid an empty display.
I've worked hard to get reasonable results out of mixed BSD
and UNIX selection, but that isn't so important. You could
give an error in that case. There are essentially 4 cases
that you have to deal with:
1. the default special case
2. BSD selection 'a' and 'x' disable filters
3. UNIX selection add processes to an empty set
4. BSD + UNIX selection error
> 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.
> Please look it over, try it out, and let me know if these options
> seem to work the way you'd expect them to, or if I have messed
> anything up. And please please PLEASE -- don't give me any more
> ideas of something *else* I could do "as long as I'm there"!
Oh. Sorry.
> Great. So what should I do here? Add a -E' option for "effective
> userid"? In fact, add both -E' and -R', and then we would have
> two options that we could MFC into 4.x as well as 5.x (without any
> conflict). At some later date (in 6.x?), we would have the option
> of changing '-U' to match the standard definition. Amazingly, both
> -E' and -R' seem to be unused on the other OS's I have here.
If you split the namespace like AIX, Tru64, and Linux do,
then you don't need these options.
> 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:
ps -u root -U albert
ps u
CMD_ENV=sysv ps -u root -U albert
CMD_ENV=bsd ps -u
ps -u # this is an error on Tru64, and a warning on Linux
> Old BSD ps used to exclude process group leaders
> unless '-g' or '-x' were given.
If you want it, I'll help somebody port the Linux ps. :-)
I'll even consider a non-LGPL license if that changes things.
Then you can enjoy near-perfect SunOS 4 goodness:
PS_PERSONALITY=sunos4 ps -aux
PS_PERSONALITY=sunos4 ps -auxg
> Well, my follow-up message explained my reasoning for this in more
> detail, but your logic seems pretty reasonable too. 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.
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1080165171.2232.910.camel>