[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#8035: Processing of .. in a file path after going thru symlink
From: |
Steve Pucci |
Subject: |
bug#8035: Processing of .. in a file path after going thru symlink |
Date: |
Sat, 19 Feb 2011 18:35:35 -0800 |
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...