Date: Sun, 27 Oct 2002 09:45:25 GMT From: Mark Valentine <mark@thuvia.demon.co.uk> To: Mike Barcroft <mike@freebsd.org> Cc: freebsd-standards@freebsd.org Subject: Re: /usr/posix: a first cut Message-ID: <200210270945.g9R9jPv7029199@dotar.thuvia.org> In-Reply-To: <20021026184928.E47672@espresso.q9media.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> From: Mike Barcroft <mike@freebsd.org> > 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 <mark@thuvia.co.uk> <http://www.thuvia.co.uk>; "Tigers will do ANYTHING for a tuna fish sandwich." Mark Valentine uses "We're kind of stupid that way." *munch* *munch* and endorses FreeBSD -- <http://www.calvinandhobbes.com>; <http://www.freebsd.org>; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200210270945.g9R9jPv7029199>