Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 25 Mar 2004 20:17:45 +0100
From:      Jilles Tjoelker <jilles@stack.nl>
To:        Albert Cahalan <albert@users.sf.net>
Cc:        drosih@rpi.edu
Subject:   Re: PATCH for a more-POSIX `ps', and related adventures
Message-ID:  <20040325191745.GB71731@stack.nl>
In-Reply-To: <1080165171.2232.910.camel@cube>
References:  <1080165171.2232.910.camel@cube>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

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

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

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

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.

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

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

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

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

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.

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

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

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

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

* 'sl' keyword doesn't work

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.

Also, in SUSv3 ps (with XSI extensions) there's no -o equivalent for the
default output, -f and -l.

-- 
Jilles Tjoelker



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040325191745.GB71731>