From owner-freebsd-standards Tue Jun 11 18:13:51 2002 Delivered-To: freebsd-standards@freebsd.org Received: from smtp.noos.fr (racine.noos.net [212.198.2.71]) by hub.freebsd.org (Postfix) with ESMTP id 98A7C37B40E for ; Tue, 11 Jun 2002 18:13:34 -0700 (PDT) Received: (qmail 9572501 invoked by uid 0); 12 Jun 2002 01:13:32 -0000 Received: from unknown (HELO gits.gits.dyndns.org) ([212.198.230.194]) (envelope-sender ) by 212.198.2.71 (qmail-ldap-1.03) with SMTP for ; 12 Jun 2002 01:13:32 -0000 Received: from gits.gits.dyndns.org (s2wjesjnn2zdbipc@localhost [127.0.0.1]) by gits.gits.dyndns.org (8.12.3/8.12.3) with ESMTP id g5C1DVa6075524; Wed, 12 Jun 2002 03:13:32 +0200 (CEST) (envelope-from root@gits.dyndns.org) Received: (from root@localhost) by gits.gits.dyndns.org (8.12.3/8.12.3/Submit) id g5C1DUR1075523; Wed, 12 Jun 2002 03:13:30 +0200 (CEST) (envelope-from root) Date: Wed, 12 Jun 2002 03:13:30 +0200 From: Cyrille Lefevre To: Juli Mallett Cc: standards@FreeBSD.org Subject: Re: cvs commit: www/en/projects/c99 index.sgml Message-ID: <20020612011330.GA45415@gits.dyndns.org> References: <200206070217.g572HH584853@freefall.freebsd.org> <20020606194448.A23497@FreeBSD.ORG> <20020611030857.GB14401@gits.dyndns.org> <20020610202431.A30207@FreeBSD.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20020610202431.A30207@FreeBSD.ORG> User-Agent: Mutt/1.3.99i Organization: ACME X-Face: V|+c;4!|B?E%BE^{E6);aI.[< List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Jun 10, 2002 at 08:24:33PM -0700, Juli Mallett wrote: > * Cyrille Lefevre escriur=C3?res [snip] > task. There's a lot of different approaches that could be taken with dea= ling > with ps(1), as it's one of those unpleasent situations where compromises,= etc., some of the possible approaches are : 1) a la HPUX : use an environment variable (UNIX95) to deal w/ some standar= d. 2) a la Tru64 or AIX : BSD options aren't dash (-) prefixed. 3) a la SunOS : use different commands located in different paths. 4) yet another approach : use a different command name to deal w/ some stan= dard. 5) try to merge BSD and System V options. in my opinion, this is really possible except by breaking the former or the later standard since similar options may behave differently such as -u (different meaning) or -j (different output). 6) use a command line option to switch from one or the other behaviour. the current implementation complies w/ 1), 2), 4) and 6). > may be made, and it's important those things aren't in the hands of one s= ingle > person, and I'm an agreeable person, and as such happy to coordinate to c= ome ^^^^^^^^^^^^^^^^^^^^^^^^ I'm sure you are :) > up with the best conformant ps(1) we can have! :) >=20 > > ps(1) I'm working on. >=20 > Thanks. you're wecome. > > PS : I've tryed to subscribe to this list twince w/o success, any ideas= ? >=20 > majordomo can be difficult, a message to majordomo@FreeBSD.org with conte= nts > of "subscribe freebsd-standaards" or "subscribe standards" should work. found the problem, I've tryed to subscribe w/ different from (the one in the header) and subscribe (the one in the body) addresses while they MUST be the sames. [snip] > > differences between BSD and SUSV3 ps(1). also, the manual would > > have to be updated to reflect the reallity (any volunteer ? :). >=20 > The manual page may prove to be one of the least pleasent tasks, as while > SUS/POSIX has taken from BSD manpages before, we are not allowed to use > their text. don't know that ! [snip] > > new compilation flags : > >=20 > > COMPAT_BSD44 > > be strictly compatible w/ BSD44 ps, else : > > * -p, -t and -U respectively accept a list of pids, ttys > > or users instead of a single one. > > * -t accept ttyXX in addition to /dev/ttyXX and XX. > > * -U also accept uids in addition of user names. > > * output is formated more intelligently when combining > > options such as -j, -l, -u and -v. format strings are > > combined instead of being concatenated. > > * -o keyword=3Dheader now works for aliased keywords, also, > > -o keyword=3D don't print an empty line anymore, if any. > >=20 > > COMPAT_SUSV2 > > be compatible w/ SUSV2 ps if the SUSV2 environment variable > > has a non-zero value or if called as ps5. this may be > > overriden using the new -B (BSD) or -V (SUSV2) options. > > SUSV2 is automagically disabled when using pre BSD44 options. > > SUSV2 options are, in fact, almost the SYSV ones. > >=20 > > here is the usage string : > >=20 > > usage: ps [-AaBdefjl] [-C cmdlist] [-g pgrplist] [-G grouplist] [-o fmt] > > [-p pidlist] [-t ttylist] [-u userlist] [-U userlist] > > [-m core] [-n system] [-w swap] > >=20 > > here are the new -o keywords w/ their BSD44 counterpart, > > if any, in parentheses : > >=20 > > addr (paddr), args (command), c, comm (command), > > etime, group, l (state), rgroup and stime. > > and the ones which are affected when SUSV2 is enable : > >=20 > > pri and time. forgot `sid' which isn't implemented yet. > Why can't these be there by default? there are, but their output is different from BSD and SystemV. let's try : # ps5 -VO pri,time | head -2 PID PRI TIME TT COMMAND 1326 32 00:00:00 p0- sh # ps5 -BO pri,time | head -2 PID PRI TIME TT STAT COMMAND 1326 10 0:00.53 p0- I /bin/sh /etc/rc.local.netstat PS : just added -O to SystemV options as SUSV3 authorize it on BSD implementations of ps(1). > > NO_SWAP > > disable -W option since kvm(3) doesn't read swap for almost > > 10 years. > >=20 > > also, single-linked tail queues have been converted to queue(3). >=20 > This is a mixed thing. Some people will rightly say that conversion of a > simplistic paradigm of code to the queue(3) constructs can be obfuscatory, > and certainly macros which evolved after 4.3BSD sometimes differ in their > meaning. TAILQ_FOREACH{,_REVERSE} on OSX bit me particularly hard. I do that last year after reading a thread asking to do so. ask O'brien (probably) for details :) > > Index: Makefile > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > RCS file: /home/ncvs/src/bin/ps/Makefile,v > > retrieving revision 1.13 > > diff -u -r1.13 Makefile > > --- Makefile 17 Nov 1999 13:37:30 -0000 1.13 > > +++ Makefile 11 Jun 2002 03:02:38 -0000 > > @@ -9,7 +9,12 @@ > > # keep ps from being an unnecessary load > > # on large systems. > > # > > -CFLAGS+=3D-I${.CURDIR}/../../sys -DLAZY_PS > > +CFLAGS=3D -g > > +CFLAGS+=3D -I${.CURDIR}/../../sys > > +CFLAGS+=3D -DBACKWARD_COMPATIBILITY > > +CFLAGS+=3D -DLAZY_PS > > +# CFLAGS+=3D -DCOMPAT_BSD44 > > +CFLAGS+=3D -DCOMPAT_SUSV2 > > DPADD=3D ${LIBM} ${LIBKVM} > > LDADD=3D -lm -lkvm > > #BINGRP=3D kmem >=20 > There should be a make(1) tunable to handle the SUS compatability so that since BSD and SystemV ps are really different in some way, it would be better to consider a runtime (evan sysctl, why not ?) tunable to deal w/ SUS compatability than a static make(1) tunable. considering a runtime tunable, the current DEFINES in use are more there to mark the code change than to make a choice between behaviours. w/ COMPAT_BSD44 undefined, -p and such options allow a pidlist and combining -j and such options is done more intelligently than before. w/ COMPAT_SUSV2 define, you may switch from BSD and SUS behaviour. that's all. in other words, I'm really against breaking whatever compatibility using some compromise. > a system being tested for standards conformance could have a flag such > as: > POSIX_CONFORM=3D NOBSD >=20 > To disable BSD things that conflict with POSIX and use POSIX instead, or: > POSIX_CONFORM=3D NOCONFLICT >=20 > To use POSIX things where there's no conflict with BSD, but which are not > meaningful in BSD (things related to sysv runtimes come to mind).=20 IMHO, nothing is not meaningfull in BSD nor nothing is meaningfull in Syste= mV. they just do the same work differently and should continue this way to not broke anything. > The rest of it looks straightforward in places, but some of the changes l= ook > a bit big and I'd like to see what later comes up wrt susv3 and patches t= o the > current version of ps(1). well, I should have run diff -w to reduce the diffs but not so much (64 lines less, that's all). for instance, I've just reprinted all ps(1) manual pages from BSD, SUSV3, HP-UX 11, Tru64 5, Solaris 9 and AIX 5 and will try make a big table of compatibilities against each other with a priority to BSD and SUSV3 of course, then, I could make a good comparison w/ the current code and finish the work :) Cyrille. --=20 Cyrille Lefevre mailto:cyrille.lefevre@laposte.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message