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>