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

From: Jilles Tjoelker (jilles+fbsd-arch_at_stack.nl)
Date: 05/28/04

  • Next message: Cyrille Lefevre: "Re: The Design and Implementation of the FreeBSD Operating System" 
    Date: Fri, 28 May 2004 17:51:40 +0200
To: Garance A Drosihn <drosih@rpi.edu>

    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
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
  • Next message: Cyrille Lefevre: "Re: The Design and Implementation of the FreeBSD Operating System"