From owner-freebsd-arch@FreeBSD.ORG Sat Jun 12 14:01:11 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F6D916A4CE for ; Sat, 12 Jun 2004 14:01:11 +0000 (GMT) Received: from ioskeha.hittite.isp.9tel.net (ioskeha.hittite.isp.9tel.net [62.62.156.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id BAC1343D41 for ; Sat, 12 Jun 2004 14:01:10 +0000 (GMT) (envelope-from clefevre-lists@9online.fr) Received: from pc2k (67-61-118-80.kaptech.net [80.118.61.67]) by ioskeha.hittite.isp.9tel.net (Postfix) with SMTP id 0137617B6CE; Sat, 12 Jun 2004 16:01:38 +0200 (CEST) Message-ID: <038901c45085$a08bde90$7890a8c0@dyndns.org> From: "Cyrille Lefevre" To: , "Garance A Drosihn" References: <200406041933.i54JX9kj040764@mail.gits.dyndns.org> Date: Sat, 12 Jun 2004 16:00:32 +0200 Organization: ACME MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Subject: Re: Change to "kludge option processing" in /bin/ps X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jun 2004 14:01:11 -0000 "Garance A Drosihn" 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 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@laposte.net