"readlink" ... / was: Re: ksh93 Integration Update 1 Amendments 1

[Roland Mainz]

Nicolas Williams wrote:
> On Wed, May 28, 2008 at 09:33:10PM +0200, Roland Mainz wrote:
> > > Huh?  This share is supposed to be shared?  If that was the case is should
> > > be /usr/gnu/... and /usr/share/gnu/...
> >
> > Well... it's still better having the GNU stuff seperate... we're still
> > suffering from the GNU parts like "readlink" which went into /usr/bin/
> > and then turned to be out the greatest abdominations ever
> > (<rant>sometimes, at night... when it's 4AM and I hit problems with 'GNU
> > "readlink" vs. uncommon fileystem' I am dreaming about appealing the
> > whole /usr/gnu/ ARC case because of the GNU "readlink"
> > <censored>-stuff</rant> (yes... I've talked to Stephen Hahn about that a
> > while ago... but then more important stuff burried the subject... ;-(
> > )).
> 
> Well, so here we have multiple ways in which "keywords" evolution can
> blow things up:
> 
>  - ksh93 can grow new keywords that blow up existing scripts
> 
>  - /usr/bin can grow new executables that conflict with ksh93 built-ins
>    (is that correct?)

The issue is not about conflicting builtins - the issue is that GNU
"readlink" has options which won't work on all types of filesystems (and
are therefore not portable). The part where it because sour was that we
developed our own POSIX-conformant version of "readlink" which doesn't
have these conflicting options (nor uses homegrown code for symlink
traversal) but were "hit by the truck" when we realised that the
/usr/gnu/ ARC case just squatted the place in /usr/bin/ instead of
/usr/gnu/bin/ (which rendered our work useless; our version is a subset
of GNU "readlink" and we can't add the conflicting options because there
is no portable way to implement it (since we only want builtins in ksh93
which are guranteed to be portable across all platforms and OSes to
allow people to write fully portable shell scripts)).

Anyway... I suggest to drop this subject... otherwise I may just go mad
and appeal the whole /usr/gnu/ ARC case (there is more stuff which was
IMO not done right but fixing it at the ARC level takes much time -
which I don't have right now... ;-( ).

> Something should be done about each of those two problems.  I'm not sure
> what easy answers might exist for the latter, short of maintaining a
> namespace registry somewhere for shell and distro maintainers.

Technicially the namespace seperation is done with PATH (and for shell
functions via FPATH), however the LSB/FHS stuff weakened that and the
/usr/gnu/-ARC case started digging a grave (by leaking GNU tools to
/usr/bin/ without having the 'g'-prefix) for the originally quite good
design of using PATH for seperating namespaces at the shell level.

> Not this case...

Right... let's drop the "readlink" topic, please...
... but a "registry" may be interesing... however my optinion is that
the GNU stuff should only end-up in /usr/bin/ if it fully passes the
POSIX test suite and is CSI-conformant.

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)