Marcel Telka wrote:
> Yes. I know. We do not want NOW another implementation of ls, but for
> future: What will be happen?
When a proposal is made to do something that triggers this scenerio,
rest assured that we will discuss it and figure out the right thing
to do.
The key point here is NOT "who implemented it?", but rather "what
architecture does it expose?". It may well be that the new thing is
upwards compatible with that found in /usr/bin, and could simply
replace it. This is *exactly* what we do every time we fix a bug in
/bin/ls - the new version simply replaces the old version with no
architectural repercussions :-)
The problem with the /usr/gnu stuff is that, in general, its exposed
architecture is somewhat "incompatible" with the corresponding POSIX
commands already found in /usr/bin, and those commands already export
Committed interfaces that can not be changed without causing problems
with consumers.
The proposal gives you the best of both worlds:
If you care about being backwards compatible, set
PATH=/usr/bin:...
If you want the GNU versions instead, set
PATH=/usr/gnu:/usr/bin:...
-John
