Change to "kludge option processing" in /bin/ps

[Cyrille Lefevre]

"Garance A Drosihn" <drosih at rpi.edu> wrote:
> At 5:34 PM -0400 6/4/04, Garance A Drosihn wrote:
> >At 10:13 PM +0200 6/3/04, Cyrille Lefevre wrote:
> >>
> >>ok, let's try another issue :
> >>
> >># ps -G " nobody "
> >>   PID  TT  STAT      TIME COMMAND
> >>75483 con- S      0:10.97 /usr/local/sbin/junkbuster configfile
> >># ps -G ,nobody,
> >>ps: Invalid (zero-length) group name
> >>ps: Invalid (zero-length) group name
> >># ps -G ,
> >>ps: Invalid (zero-length) group name
> >>ps: Invalid (zero-length) group name
> >
> >
> >>why do you make a difference while parsing commas and spaces ?
>
> When I first read this, I thought you meant that my latest `ps' was
> not accepting blanks somewhere that it should have.
>
> Now that I read it closer, it seems that you want me to treat a
> comma the same as a blank.  The spec that I am reading from talks
> about "in the form of a <blank> or comma-separated list".  To me,
> that means "a list which is separated by one or more spaces or
> tabs, or by a comma".  Thus, one comma must be a separator between
> two elements in a list.

no, it means by one or more spaces, tabs or commas, not just one or more
spaces or tabs, or only one a comma.

let's see what other OSes does :

$ uname -a
HP-UX spe173 B.11.23 U ia64 2124664568 unlimited-user license
$ ps -p "  1432  1434  "
ps: wrong PID number
  PID TTY          TIME CMD
 1432 ?           00:00 nfsd
 1434 ?           00:00 nfsd
$ ps -p "1432  1434  "
  PID TTY          TIME CMD
 1432 ?           00:00 nfsd
 1434 ?           00:00 nfsd
$ ps -p "1432 1434"
  PID TTY          TIME CMD
 1432 ?           00:00 nfsd
 1434 ?           00:00 nfsd
$ ps -p , # or ""
ps: wrong PID number

same results using one or more commas in place of one or more spaces.
well, HP-UX seems to be broken a lot, sine it doesn't accept a leading space !

$ uname -a
OSF1 spe147.testdrive.hp.com V5.1 2650 alpha
$ ps -p "  1197  1204  "
       PID TTY      S           TIME CMD
      1197 ??       I        0:00.16 /usr/dt/bin/dtfile -dir ~ -geometry +700+0
      1204 ??       I        0:00.00 /usr/dt/bin/dtfile -dir ~ -geometry +700+0
$ ps -p ",,1197,,1204,,"
       PID TTY      S           TIME CMD
      1197 ??       I        0:00.16 /usr/dt/bin/dtfile -dir ~ -geometry +700+0
      1204 ??       I        0:00.00 /usr/dt/bin/dtfile -dir ~ -geometry +700+0
$ ps -p , # or ""
(all processes !)

well, tru64 seems to be broken here, since -p "" means -e !

$ uname -a
SunOS ss20 5.8 Generic_108528-05 sun4m sparc SUNW,SPARCstation-20
$ ps -p "  465  466  "
   PID TTY      TIME CMD
   465 ?        0:00 httpd
   466 ?        0:00 httpd
$ ps -p ",,465,,466,,"
   PID TTY      TIME CMD
   465 ?        0:00 httpd
   466 ?        0:00 httpd
$ ps -p , # or ""
ps:  is an invalid non-numeric argument for -p option
(usage string)

I have no irix boxes under my hand, but the manual irix page is more
clear about what ps does regarding how it handle lists arguments :

http://minilien.com/?kL0OU9x9y6
 or
http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=man&fname=/usr/share/catman/u_man/cat1/ps.z&srch=ps

"options accept names or lists as arguments.  Arguments can be either
separated from one another by commas or enclosed in double quotes and
separated from one another by commas or spaces."

> So, `ps -G ,nobody,' is a list with three elements, two of which
> are null.  Null elements are an error.  So, you get two error
> messages.  As I sit here right now, I still think that is the
> correct and reasonable behavior, so I have no plans to change it.

think about not well formed shell script. it isn't necessary to
display an error message like this, more important, ps should not
stop on such error, al least, it should display process info for
non- empty elements. however, it's far better than to believe ,,
means 0 :) imagine something like :  ps -o pid= ,, | xargs kill

> I can see that it could be argued that leading or trailing blanks
> should also be considered a separator, and should also cause an
> error.  I prefer the present behavior, but I will change that to
> generate an error if people really think it should be.

except HP-UX which isn't homegeneous (warn about a leading space, but
don't on a terminating one !), all other OSes ignore leading and
terminating spaces or commas, and consider multiple spaces or commas
as one w/o unnecessary warnings.

Cyrille Lefevre.
-- 
home: mailto:cyrille.lefevre at laposte.net