filename expansion (was r80 - trunk/packages/jed/debian)

[Jörg Sommer]

Hallo G.,

G. Milde schrieb am Mon 26. Sep, 09:16 (+0200):
> On 24.09.05, Jörg Sommer wrote:
> > > > > 
> > > > > -  $ jed-script /tmp//test.sl
> > > > > -  Unable to load /test.sl
> > >  
> > > > I've looked in SuSv3 4.11 Pathname Resolution and I would tend to say the
> > > > behaviour is wrong. Multiple slashs should be treated as one slash. But
> > > > I'm not really sure and need to have a closer look to this.
> > > 
> > > The behaviour is consistent with filename expansion in jed:
> 
> > >    For example, under Unix, if `file' has the value `"/a/b/../c/d"', it
> > >    returns `"/a/c/d"'.  Similarly, if `file' has the value
> > >    `"/a/b/c//d/e"', `"/d/e"' is returned.
> > > 
> > > as such it should be considered a "feature".
>  
> > It's a bad feature. If the path is concatenated from two variables, you
> > need to take care of the end/begin of the variable. This may trigger
> > some strange problems or you use a special function path_concat(), as
> > it is done. 
> 
> It is nice to have if you want to give a path in the minibuffer.
> If you want e.g. /etc/something, instead of deleting the init string,
> you can simply write "/etc/some " and the space lets the whole thing
> expand to the searched for path. (I suppose this is why this "feature"
> was introduced by John.)

After a discussion in <news:de.comp.os.unix.misc> I can say, it is a
violation of the SuSv3 -- the Unix-Standard. I will talk to John.

Bye, Jörg.
-- 
Der kommt den Göttern am nächsten, der auch dann schweigen kann,
wenn er im Recht ist.                         (Cato; 234-149 v. Chr.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-jed-devel/attachments/20050930/fce0c516/attachment.pgp