The case was approved as specified during yesterday's PSARC meeting
Casper
Template Version: @(#)sac_nextcase %I% %G% SMI
This information is Copyright 2009 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
Unified ps(1)
1.2. Name of Document Author/Supplier:
Author: Casper Dik
1.3 Date of This Document:
09
First off, I really like what this case is trying to do. But I do have
a possible concern: /usr/ucb/ps could have been used with a leading
-. E.g. /usr/ucb/ps -aux and /usr/ucb/ps aux both return the same thing.
I'd humbly suggest that if getexecname returns /usr/ucb/ps then the
legacy UCB
Garrett D'Amore writes:
First off, I really like what this case is trying to do. But I do have
a possible concern: /usr/ucb/ps could have been used with a leading
-. E.g. /usr/ucb/ps -aux and /usr/ucb/ps aux both return the same thing.
I'd humbly suggest that if getexecname returns
First off, I really like what this case is trying to do. But I do have
a possible concern: /usr/ucb/ps could have been used with a leading
-. E.g. /usr/ucb/ps -aux and /usr/ucb/ps aux both return the same thing.
I'd humbly suggest that if getexecname returns /usr/ucb/ps then the
legacy
Hmm... maybe I didn't understand. As long as /usr/ucb/ps behaves as
/usr/ucb/ps whenever any valid syntax that was accepted by it today is
given, then I'm ok with it. (And understanding that - is a valid part
of the syntax. :-)
Indeed. And yes, ps -xuag works as you expect when you
Garrett D'Amore wrote:
That said, I do sort of think that the rule you have, while workable, is
more confusing and violates the principle of least surprise.(I.e.
you added a switch by accident which suddenly changed the meaning of
other options in a totally unexpected fashion.)
This
Scott Rotondo wrote:
Garrett D'Amore wrote:
That said, I do sort of think that the rule you have, while workable,
is more confusing and violates the principle of least surprise.
(I.e. you added a switch by accident which suddenly changed the
meaning of other options in a totally
Scott Rotondo writes:
Garrett D'Amore wrote:
That said, I do sort of think that the rule you have, while workable, is
more confusing and violates the principle of least surprise.(I.e.
you added a switch by accident which suddenly changed the meaning of
other options in a totally
Depending on the presence of - isn't novel. Other OSes have done
this before. Inspecting the options in a presumed-BSD-ish list and
reverting to SVR4 behavior if an unexpected option is seen _is_ new,
and it's what caused both Garrett and me to say something.
I understand. Clearly, I wanted
Ceri Davies writes:
On Mon, Feb 09, 2009 at 10:36:35PM +0100, Casper.Dik at sun.com wrote:
This kind of precludes adding any new options to /usr/ucb/ps, ever. I
don't believe that this is a particularly bad thing, just want to be
crystal clear that this is what we want to do.
As
+1 to the change along with Garrett's suggestion, which I understand
to be in priority order:
/usr/ucb/ps - only BSD flags, regardless of -
- present - only USL flags
no - - only BSD flags
+1 I can then stop having to remember which ps path I have to type
Gary..
12 matches
Mail list logo
