From owner-freebsd-standards Sun Oct 27 1:45:32 2002 Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9393D37B401; Sun, 27 Oct 2002 01:45:29 -0800 (PST) Received: from thuvia.demon.co.uk (thuvia.demon.co.uk [193.237.34.248]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A50343E42; Sun, 27 Oct 2002 01:45:28 -0800 (PST) (envelope-from mark@thuvia.demon.co.uk) Received: from dotar.thuvia.org (dotar.thuvia.org [10.0.0.4]) by phaidor.thuvia.org (8.12.3/8.12.3) with ESMTP id g9R9jQcF055980; Sun, 27 Oct 2002 09:45:26 GMT (envelope-from mark@thuvia.demon.co.uk) Received: from dotar.thuvia.org (localhost [IPv6:::1]) by dotar.thuvia.org (8.12.6/8.12.6) with ESMTP id g9R9jPH5029200; Sun, 27 Oct 2002 09:45:25 GMT (envelope-from mark@dotar.thuvia.org) Received: (from mark@localhost) by dotar.thuvia.org (8.12.6/8.12.6/Submit) id g9R9jPv7029199; Sun, 27 Oct 2002 09:45:25 GMT Date: Sun, 27 Oct 2002 09:45:25 GMT From: Mark Valentine Message-Id: <200210270945.g9R9jPv7029199@dotar.thuvia.org> In-Reply-To: <20021026184928.E47672@espresso.q9media.com> X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Mike Barcroft Subject: Re: /usr/posix: a first cut Cc: freebsd-standards@freebsd.org Sender: owner-freebsd-standards@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > From: Mike Barcroft > Date: Sat 26 Oct, 2002 > Subject: Re: /usr/posix: a first cut > > > I would prefer to have /usr/posix/bin and /usr/posix/man. I think > > > manuals will get too cluttered if we try to document two differing > > > utilities in one manual. > > > > I was hoping this wouldn't get that much out of hand; I see the > > differences being very small. > > I don't. Take for instance /usr/posix/bin/ps which will be completely > different, with many conflicting options. Ah, I guess XSI stuff makes more if a difference, if we choose to support it. > > Most users will never see the POSIX-related manual pages if they > > are separate. > > Users that don't need POSIX-conformant applications won't need to read > about conformant versions and vice versa. I'm a bit worried that this just hides standards-based manual pages behind the compatibility ones. > > Do you know of any other systems which take this approach? I've > > sort of been following Solaris' style, which I've found to be effective. > > Take a look at the sccs(1) manual on Solaris to see why I think > manuals get cluttered when you go that route. More XSI stuff. Hmm, would a hybrid route work? Shared manual pages for base POSIX.1 stuff, and separate ones for XSI? Our stuff is mostly POSIX.1, but it will never be "mostly XSI". Actually, I think I'm becoming unkeen on the idea of a "getconf PATH" which delivers System V utilities instead of BSD ones. Can anyone think of a mechanism to opt out of the XSI stuff but still get the base POSIX.1-2001 environment? How about having a separate /usr/sysv/bin? Do you have any ideas for implementing conditional processing of manual pages? Preferably the mechanism would allow pre-processed pages to remain syntactically correct and make some degree of sense when fed through nroff -man. My guess would be to use .ifdef POSIX and massage it for feeding through unifdef -t (I've used this technique in the past to pre-process ifdef's in GNU-style makefiles). > > > I think we should suggest in posix(7) that users seeking conformant > > > utilities change their PATH and MANPATH. > > > > I explicitly didn't do that, because I think /usr/posix is there for > > script writers, not users. > > I think both will be using it. OK. I posted an update for this in another message, and will modify it to refer to getconf(1). > > In fact, putting /usr/posix at the start of your path is more likely > > to _break_ the scripts you run. > > I use a different shell for scripting (/bin/sh) vs. my regular shell > (/bin/tcsh). A run of w(1) on freefall shows I'm not alone, 0/27 > users are running sh(1). I believe most advanced Bourne shells define > something to distinguish themselves from regular /bin/sh, so it > shouldn't be a problem to change the path only for interactive > sessions. I was only talking about interactive sessions... Cheers, Mark. -- Mark Valentine, Thuvia Labs "Tigers will do ANYTHING for a tuna fish sandwich." Mark Valentine uses "We're kind of stupid that way." *munch* *munch* and endorses FreeBSD -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message