filename expansion (was r80 - trunk/packages/jed/debian)
joerg at alea.gnuu.de
Fri Sep 30 20:48:31 UTC 2005
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.
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
Size: 481 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-jed-devel/attachments/20050930/fce0c516/attachment.pgp
More information about the Pkg-jed-devel