Date: 28 Mar 2004 20:23:56 -0500 From: Albert Cahalan <albert@users.sf.net> To: Stephen McKay <smckay@internode.on.net> Cc: Albert Cahalan <albert@users.sourceforge.net> Subject: Re: posix ps (was Re: Adding `pgrep' and `pkill' to /usr/bin) Message-ID: <1080523435.2255.1869.camel@cube> In-Reply-To: <200403290042.i2T0g2sv003657@dungeon.home> References: <p0602046abc879c5fe2f9@[128.113.24.47]> <20040325070120.GA67497@VARK.homeunix.com> <1a9c01c41359$b3da45e0$7890a8c0@dyndns.org> <p06020494bc8a5738af2f@[128.113.24.47]> <200403280808.i2S88aJ7016011@dungeon.home> <20040328184244.I10175@beagle.fokus.fraunhofer.de> <200403290042.i2T0g2sv003657@dungeon.home>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1080523435.2255.1869.camel>