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