Skip site navigation (1)Skip section navigation (2)
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>