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

G. Milde g.milde at web.de
Mon Sep 26 07:16:59 UTC 2005


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.)

I agree that it is annoying if your are building paths from variables (at
least as long as you know, that all your paths are Unix style).

> But that is not a typical doing elsewhere.
> I would indicate this as a bug not a feature. But I must look into SuSv3
> before I'm sure.

I suppose that John will tell you that path_concat() is "the right
thing"(TM), as this will make your code OS independent. But feel free to
give it a try.

Guenter

-- 
G.Milde web.de



More information about the Pkg-jed-devel mailing list