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

[Albert Cahalan]

On Thu, 2004-03-25 at 14:17, Jilles Tjoelker wrote:
> On Wed, Mar 24, 2004 at 04:52:52PM -0500, Albert Cahalan wrote:
> > 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.
...
> I think that has been a historical mistake in the POSIX standardization.
> tar/cpio were not standardized, instead a new utility "pax" was
> invented. This should have been done with ps too, as the BSD and System
> V versions are thoroughly incompatible. Instead, they made some
> half-hearted attempt at making up some compatible subset. This may be
> the source of the little-used '-A' option (equivalent to '-e' which is
> used much more often).

I would agree, except that nobody uses pax. :-)
 
> > 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.
> 
> I think this is ugly.  Also, scripts and users on BSD have started to
> use a hyphen on BSD-style options, e.g. ps -ux. It may be the least bad
> way out, though.

Ultimately, it is the least bad way out. You might want to
add a /usr/ucb/ps though. Then users can set $PATH to that
when they want 100% old BSD behavior. Sun does this.

Consider making /usr/ucb/ps a trivial script wrapper that
sets an environment variable rather than having the main
ps executable look at the path.

> > >      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.
> 
> -O sig,sigmask,sigignore,sigcatch does about that, but requires more
> typing. The hexadecimal numbers are still annoying.

How odd that you've lost "ps s" but retained the ability
to produce the data! Zero-padded hex is pretty reasonable;
it would allow you to count from either side.

> Hmm, I rather like a getopt-based parser for the complicated stuff.
> However, when the first argument doesn't start with a hyphen, FreeBSD ps
> does weird things and I have at least one PR on file about that
> ('ps tpt').

The common non-getopt parser crams everything into one
big ugly while() loop. You needn't do that; simply break
things up a bit as you would for any other code. It's
quite readable that way. For example, hack-free handling
for "t" is nicely localized:

case 't': /* Select by tty. */
  /* List of terminals (tty, pty...) _should_ follow t. */
  arg=get_opt_arg();
  if(!arg){
    /* This is old BSD syntax. Put our tty on a tiny list. */
    /* ... snip ... */
    return NULL;
  }
  err=parse_list(arg, parse_tty); /* parse_tty is a function */
  if(err) return err;
  selection_list->typecode = SEL_TTY;
  return NULL; /* can't have any more options */

> It has been discussed on freebsd-standards or -arch. Users may set
> CMD_ENV=sysv if they want to use System V style options, but scripts
> will not expect that. This requires all scripts using ps to be changed.

Yes and no. You only have to break scripts using options
that could be parsed either way. For example, my parser
falls back to BSD mode if it sees "ps -axu". It also falls
back to BSD mode for "ps -aux" if user "x" doesn't exist.
Due to "x" being a commonly-used BSD-only option, it is
rare to have a command that can parse either way. To gently
break old habits, I give a warning when fall-back parsing
is used.

> Separate paths or names for the two seem like a better way. It seems
> best that it's one binary that changes behaviour depending on argv[0],
> but that makes it hard to call both of them by the name "ps".

Sun is already using /usr/ucb for this. I suspect many
people have this in their $PATH already.

> > 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
> 
> I use almost all options of FreeBSD 4.x ps now and then, with
> exception of the obscure '-C' option and the sorting options.
> 
> I'm not especially fond of Linux ps. Some of my annoyances are:
> 
> * It's over-complicated, supports options from many Unix variants.
>   This may be unavoidable in the end, though.

Sure. Your HP-UX scripts will work though.

> * 'ps axO user' doesn't show full argv ('ps ax' does)

Hmmm, that could be considered a bug. I can change this.

> * Doesn't have 'I', 'D', 's', '+' status letters

"D" is there, along with "S" and "W".
"s" and "+" seem kind of redundant, taking up valuable space.
"I" can not be supported on Linux.

> * 'sl' keyword doesn't work

It might be doable, at least approximately, on a 2.6.xx kernel.
A port to FreeBSD could of course have this working.

(Wow, somebody actually uses the "sl" keyword! Can I assume
you maintain the kernel's scheduler?)

> Of course, some of these annoyances are due to the Linux kernel and not
> due to procps itself.
>
> I don't find Linux ps as annoying as SysV ps that cannot show me all
> processes running under my uid without me mentioning my uid on the
> command line, and truncate long argv pretty quickly.

Thanks for taking a look. Did I get FreeBSD's "H" option right?
I'm not sure what the PID column is supposed to contain.
Also, I'd be happy to support a FreeBSD-compatible "Z" if you
can properly describe it to me.