posix ps (was Re: Adding `pgrep' and `pkill' to /usr/bin)

[Albert Cahalan]

On Sun, 2004-03-28 at 19:42, Stephen McKay wrote:
> On Sunday, 28th March 2004, Harti Brandt wrote:
> 
> >Well, that is just like LANG or LC_ALL. You cannot depend on parsing
> >utility output until you set LC_ALL=C, yet I have still to see a script
> >that does this.
> 
> Yes, that is a significant deficiency of the internationalisation scheme.
> That doesn't mean we should copy it though.

At least this is proof that the idea is nothing crazy.
It has problems, but then so does everything else.

> >If you happen to write a script for BSD syntax just put LC_ALL=C
> >PERSONALITY=BSD on top of it.
> 
> Hopefully in the near future there will be a universally accepted default
> for ps options.  Are you seriously suggesting that every script forevermore
> will have to put PERSONALITY=STANDARD (or similar) in front of a two
> character command name just to defeat this misfeature?

Generally, no. You set the personality when you run
a large, complicated, or read-only script that expects
some non-default behavior.

The man page can document that "stuff may break".
Users, especially those not doing sysadmin work,
are free to take that risk.

Personality support is a compatibility hack. You use
it to make stuff work, not to break things.

> >SM>If multiple personalities is a desirable trait (and it's not clear that it
> >SM>is) then command line switches and aliases are the correct mechanisms to
> >SM>use.
> >
> >That would require to add that switch to all utility calls in a script
> >that have multiple personalities. Thats far from being desirable.
> 
> I don't understand.  I was suggesting that if end users want different
> flavours of output they can select them with command line switches and
> aliases (if this is an option at all).  This is as opposed to allowing
> users to select the default via an environment variable, which would
> negatively impact the use of ps in scripts.

You have that flipped around. Personality support allows
you to make your old or foreign-OS scripts work.

If you're porting something big, throwing CMD_ENV=sysv or
CMD_ENV=bsd at the top may be the the most expedient way
to deal with things. This is especially true if you're
dealing with a commercial package designed for another OS.

> I can't see why scripts would want to use anything but the standard options.
> You only want to parse one format.

Basic multi-personality support is not difficult.
I'll call this semi-auto mode. Tru64 and AIX do this.
If CMD_ENV=bsd is set or the first option lacks a hyphen,
you parse in BSD mode. Every option goes through the
bsd switch() table. If CMD_ENV=sysv is set and the
first option has a hyphen, every option goes through
the sysv switch table.

You can get fancy. There are some tricks to make a
transition easier or more useful. For example, Linux
ps will give a warning and fall back to BSD mode if
the UNIX-style parser encounters problems. You can
allow mixed options; my users really like this.

I'll end with a chunk of my man page. Please note the comment
"In general, it is a bad idea to set these variables." applying
to all environment variables (not just personality) and the
fact that the 4 non-POSIX personalities are marked with the
comment "(totally non-standard)" to warn the users.

--------------------------------------------------------------------
ENVIRONMENT VARIABLES
The following environment variables could affect ps:
    COLUMNS             Override default display width.
    LINES               Override default display height.
    PS_PERSONALITY      Set to one of posix,old,linux,bsd,sun,digital...
    CMD_ENV             Set to one of posix,old,linux,bsd,sun,digital...
    I_WANT_A_BROKEN_PS  Force obsolete command line interpretation.
    LC_TIME             Date format.
    PS_COLORS           Not currently supported.
    PS_FORMAT           Default output format override.
    PS_SYSMAP           Default namelist (System.map) location.
    PS_SYSTEM_MAP       Default namelist (System.map) location.
    POSIXLY_CORRECT     Don't find excuses to ignore bad "features".
    UNIX95              Don't find excuses to ignore bad "features".
    _XPG                Cancel CMD_ENV=irix non-standard behavior.

In general, it is a bad idea to set these variables. The one exception
is CMD_ENV or PS_PERSONALITY, which could be set to Linux for normal
systems. Without that setting, ps follows the useless and bad parts
of the Unix98 standard.

PERSONALITY
    390      like the S/390 OpenEdition ps
    aix      like AIX ps
    bsd      like FreeBSD ps (totally non-standard)
    compaq   like Digital Unix ps
    debian   like the old Debian ps
    digital  like Digital Unix ps
    gnu      like the old Debian ps
    hp       like HP-UX ps
    hpux     like HP-UX ps
    irix     like Irix ps
    linux    ***** RECOMMENDED *****
    old      like the original Linux ps (totally non-standard)
    posix    standard
    sco      like SCO ps
    sgi      like Irix ps
    sun      like SunOS 4 ps (totally non-standard)
    sunos    like SunOS 4 ps (totally non-standard)
    sysv     standard
    unix     standard
    unix95   standard
    unix98   standard