On Thu, Dec 14, 2006 at 02:19:28PM -0800, Stephen Hahn wrote:
> Well, the split is consistent with other environments on the system.
But while the /usr/xpg[46] directories are a decent jumping-off point for
thinking about /usr/gnu, I'd be hesitant in extending the analogy too far.
The difference, I think, is in perception. /usr/xpg[46] are very small and
precisely populated, and are likely to get even less populated as what
functionality can be folded into the main utilities is (now that it's been
made explicit that they can be and should). No one could possibly mistake
them for being complete environments. I think that most people see them
as being odd little warts that you can or should use if you need special
behavior, and that most people don't.
/usr/gnu, on the other hand, provides (for) a well-known set of
functionality which, in a full implementation, provides a near-complete
unix-like environment. (I agree that some method of combining /usr and
/usr/gnu is necessary for a full Solaris experience, but that's well beyond
the scope of this project.)
Because of the relatively high population of /usr/gnu vs /usr/xpg[46], I
wouldn't expect people to look at /usr/xpg[46]/bin and say "Gosh, where are
all the missing utilities?", but I might expect that question from the same
person of a haphazardly populated /usr/gnu.
I'll also note that none of /usr/ucb, /usr/xpg[46], and /usr/ccs have their
own manual, and that for at least /usr/xpg[46], the variants are mentioned
in the mainline manpage.
> If we're arguing that this is a special environment ("near complete",
> rather than "incomplete"), then we get back to having the choice of
>
> PATH=/usr/bin:/usr/gnu/bin
>
> or
>
> PATH=/usr/gnu/bin:/usr/bin
>
> or
>
> PATH=/usr/bin
What are the other choices that my concern eliminates?
> Changing the default PATH and MANPATH settings is possible, but is
> seems always to be controversial...
And, given that these are frequently overridden by users, impossible to get
perfect.
> So you would have
>
> /usr/bin/seq -> /usr/gnu/bin/seq
>
> and so forth?
If and only if GNU components install fully into /usr/gnu.
> I believe the proposal was pretty clear about /{usr,var,etc}/gnu for
> most files, with the exception of the binaries and the info files.
I don't see that in the proposal; can you point me at the text?
> But, of course, the proposal makes all of the non-conflicting commands
> part of the path. So the only issue is manual pages. I suppose we
> could do a similar split there.
Well, then "m -al ls" (or "apropos ls" or "whatis ls", were we to populate
our windex files) will still fail to show that there are multiple
implementation of ls on the system, even if they'd find "pinky".
Danek
