bug#8035: Processing of .. in a file path after going thru symlink

[Steve Pucci <spucci@mac.com>]

On Feb 19, 2011, at 1:37 PM, Glenn Morris wrote:

> This appears to be a feature of expand-file-name (and possibly other
> things). It does seem a little weird that there isn't even an option to
> have a more thorough expansion...

So I ran an experiment, redefining expand-file-name as follows to skip the ".." processing (except in default-directory) and otherwise do the rest:

(or (fboundp 'save-expand-file-name)
    (fset 'save-expand-file-name (symbol-function 'expand-file-name)))
(defun expand-file-name (NAME &optional DEFAULT-DIRECTORY)
  (cond ((string-match "^/" NAME)
         NAME)
        ((string-match "^\\(~[^/]*\\)\\(.*\\)$" NAME)
         (let ((userdir (match-string 1 NAME))
               (rest (match-string 2 NAME)))
           (concat (save-expand-file-name userdir) rest)))
        (t (concat (save-expand-file-name (if DEFAULT-DIRECTORY
                                              DEFAULT-DIRECTORY
                                            default-directory))
                   NAME))))

While this does the trick (it expands only ~ and relative paths and properly leaves the OP path intact), it fails to fix the problem with next-error.  So I conclude you're right there are other places that do the same thing, apparently.

My workaround now is to wrap my build script in a Perl script which rewrites all "../" paths it finds within its output.  So I'm ok, though I'm surprised this hasn't come up before...