Re: expand-file-name bug.

From: Harvey J. Stein <hjstein_at_MATH.HUJI.AC.IL>
Date: Mon, 6 Nov 1995 17:21:08 +0200

Erick Gallesio writes:
> > "Harvey J. Stein" writes
>
> > Consider the following two commands:
> >
> > STk> (expand-file-name "/foo/bar/")
> > "/foo/bar"
> > STk> (dirname "/foo/bar/")
> > "/foo"
> >
> > I'm not sure how useful this stripping of the final "/" is. I've
> > found myself having to code around it alot. For me, it'd be most
> > useful if dirname would always return a string ending in "/", and
> > would return the entire string when it ends in "/". This seems to be
> > a reasonable interpretation of path semantics. Also, it's convenient
> > because one can always count on appending a filename to a dirname to
> > get full path name. Alternatively, it could do the above, but strip
> > the trailing "/". However, the latter can't really be guaranteed
> > (consider (dirname "/")).
> >
> > Similarly, expand-file-name converts directory names to file names
> > (if you consider paths ending in "/" to denote directories).
> >
> > Although in reality /foo/bar may be either a directory name or a file
> > name, the above functions need to follow some sort of convention to
> > distinguish between file names and directory names. The above
> > convention is at least consistent with RFC 1808 on URL interpretation
> > for ftp URLs.
> >
> > What do you think?
>
> The problem is that all this function works without regarding if
> the file exists. This allows to work with names of files which are
> not already created (as does the basename and dirnames Unmix
> commands). This is a constraint that I have keep in mind but I
> don't know if it is a reasonnable one. (Note: I have written a
> function canonical-path which does the same work that the
> realpath(2) function and this one of course has to use stat to see
> if some components are links...) What do you think?

Well, I don't know any more. You're right that the spec for dirname &
basename seem to imply that (dirname "/foo/bar/") should be "/foo".
I'd be hesitant to suggest breaking convention. If we're going to
have a basename & dirname for the Unix package, they had better follow
unix conventions.

On the other hand, there is a precedent for following the behaviour
that I'm recommending. Here's some CLISP output:

> (directory-namestring "foo/bar/")
"foo/bar/"
> (directory-namestring "foo/bar")
"foo/"

I read what CLTL2 has to say on the subject. I found it fairly
confusing, but it didn't seem to vote one way or another on the
subject. So, it's not clear that the above behaviour is to be
expected of lisp implementations on Unix machines.

I guess the problem is that "/foo/bar/" and "/foo/bar" really are two
different names for the same file system object. So, maybe one
shouldn't distinguish between them.

At this point, I'm willing to accept the path handling fcns as they
are. I'll just have to write my own versions for my own needs.

Thanks,

Harvey
Received on Mon Nov 06 1995 - 16:22:42 CET