Date: Fri, 28 May 2004 17:51:40 +0200 From: Jilles Tjoelker <jilles+fbsd-arch@stack.nl> To: Garance A Drosihn <drosih@rpi.edu> Cc: arch@FreeBSD.ORG Subject: Re: Change to "kludge option processing" in /bin/ps Message-ID: <20040528155139.GB85017@stack.nl> In-Reply-To: <p0602040cbcd70df2894b@[128.113.24.47]> References: <p0602040cbcd70df2894b@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, May 23, 2004 at 10:58:23PM -0400, Garance A Drosihn wrote: > After staring at the kludge-option processing in `ps' for awhile, I > found enough edge-cases where it simply did not work "right" (for my > definition of "right", at keast...), so I rewrote it. As part of that, > I also removed the ancient "BACKWARD_COMPATIBILITY" compile-time > option, where: > ps -options arg1 arg2 > (with no '-' on "arg1" and "arg2") was treated as: > ps -options -N arg1 -M arg2 > I did this because I have often been puzzled/annoyed when I type: > ps 12 > to get process 12, and then realize I wanted it shown in a > different format so I type: > ps -u 12 What you should use is 'ps u12' :) That also works on old (pre-Reno) BSD ps, and it's shorter too. It doesn't work on Solaris /usr/ucb/ps, but my ps shell function takes care of that (for me). > and I get a completely different list of processes, or I type: > ps 12 34 > and I only see process 12, or I type > ps 12 34 56 > and get the error message: > ps: 56: No such file or directory > This BACKWARD_COMPATIBILITY is not documented in the usage() > or the man page, so I'd like to replace it. Note that netstat(1) has similar backward compatibility, and gdb -k uses the same order (namelist then memory). You're right that this is rather confusing. > So, I changed `ps' to check for any additional arguments after > processing all '-'-options, and if those start with a digit then > `ps' will try to use the entire argument as a pid or pidlist. > If an extra argument does not start with a digit, then `ps' just > prints an error and exits. > I want to do more testing on this before committing, but I thought > that all this was enough of a change that I should also give people > a chance to scream before I commit it. Also, I'm not sure if I > might have clobbered some subtle aspect of the kludge processing. > If anyone wants to try the update, it is available at: > http://people.freebsd.org/~gad/ps-kludge.diff > [disclaimer: at the moment it's only had about 15 minutes of > testing, but I *think* this is about the way I want it to work] > Assuming there aren't any major objections to these ideas, I plan > to do some more testing on this and commit it next weekend. Unfortunately, I can't try it out because I don't have access to a very recent -CURRENT. What's the deeper purpose of the `optlist' argument for `kludge_oldps_options' if it's always set to PS_ARGS? I have some doubts on whether `ps t' instead of `ps T' should still be supported, since `ps t p0' doesn't work because of it. You could only change 't' to 'T' when there are no more arguments. Am I right that `ps U0' is equivalent to `ps -U0' with the patch? (This wasn't really much of an issue before `-U' accepted uids instead of names.) What happens when you do `ps 1,2,3,4'? And `ps uww0,1'? Or even `ps "v1 $$"'? All this complexity makes me think of not using getopt(3), as Albert Cahalan suggested :) -- Jilles Tjoelker
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040528155139.GB85017>