Re: (concat "/dir/name/" "foo") --> (expand-file-name "foo" "/dir/name/")

[prj@po.cwru.edu (Paul Jarc)]

Dave Love <d.love@dl.ac.uk> writes:
>  PJ> In each particular case of deciding whether to use
>  PJ> expand-file-name,
> 
> I don't think you should be making any such decision.

Let me rephrase.  Whether a filename is to be expanded should be a
documented part of any interface that uses filenames.  Expansion is
generally useful for users, so it would be done for most or all user
interfaces, but not necessarily for programmatic interfaces.  (This
has the cost that a user typically can't use a name like "foo/../bar"
literally when foo is a symlink, but we can live with that.)  Then
programs have to be careful to avoid, e.g., passing an expanded (or
not expanded) name to another interface that expects an unexpanded (or
expanded) name.  You want to avoid multiple expansions in general,
since expansion need not be idempotent, and you want to avoid
expanding a name which is known to be literal but which might invoke
magic - e.g., it came from directory-files - because its expansion
might be a different name, naming a different file.  So take a name
given by the user, expand it once, then keep that expanded name for
future use, and for building other filenames.  For example:
(setq expanded-name (expand-file-name directory-name-from-user)) ; once
(setq directory-name (file-name-as-directory expanded-name))     ; once
(concat directory-name literal-relative-name)                    ; whenever

Avoiding multiple expansions also helps with performance, regardless
of the correctness problems that might occur.

> If you think you should be able to suppress contraction of ../ for
> some reason, make a bug report with enough justification.  I'm not
> convinced.

../ was perhaps a bad example.  But I can't make a bug report, because
I haven't audited all the code that uses expand-file-name to see where
names might be expanded twice.  It would be easier and faster for the
various people who've written the code to audit it themselves, if they
hadn't thought of this issue when they wrote it.  Then they'll also be
more aware of the potential problem when they write new code.

> I doubt we've changed much significant in that area, but there is a
> tarball of a more recent version of the Lisp manual somewhere on
> alpha.gnu.org.

Got it, thanks.  Yes, I see that expand-file-name,
directory-file-name, and file-name-as-directory are subject to
handlers, so idempotency cannot be generally guaranteed.  It should
probably be a goal of any handler, though.


paul