[Pkg-jed-commit] r80 - trunk/packages/jed/debian

[Jörg Sommer]

Hello G.,

G. Milde schrieb am Fri 23. Sep, 14:26 (+0200):
> On 23.09.05, Jörg Sommer wrote:
> > Hallo,
> > 
> > Guenter Milde schrieb am Fri 23. Sep, 08:37 (+0000):
> > > this is no bug, the path is expanded with expand_filename
> > > 
> > > -  $ jed-script /tmp//test.sl
> > > -  Unable to load /test.sl
> > 
> > Are you sure?
> 
>  
> > 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:
> 
>  DESCRIPTION
>    The `expand_filename' function expands a file to a canonical form.
>    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. The example where I
tumble about this issue was LIB=/usr/.../jed/ and FILE=$LIB/file.

This may trigger some strange problems or you use a special function
path_concat(), as it is done. 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.

Bye, Jörg.
-- 
Man soll Denken lehren, nicht Gedachtes.
-------------- 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/20050924/a1689481/attachment.pgp