GNU bug report logs -
#7872
Possible fix for relative pathnames given through the command line
Previous Next
Reported by: Roy Liu <carsomyr <at> gmail.com>
Date: Thu, 20 Jan 2011 02:43:01 UTC
Severity: normal
Merged with 6179,
8127
Found in version 23.2
Done: Jan Djärv <jan.h.d <at> swipnet.se>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your bug report
#7872: OSX: Emacs.app is loading files specified by relative pathname twice
which was filed against the emacs,ns package, has been closed.
The explanation is attached below, along with your original report.
If you require more details, please reply to 6179 <at> debbugs.gnu.org.
--
7872: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7872
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
It seems the right thing to do. Checked in. In the future, please use M-x
report-emacs-bug so we can see the version you are reporting against. The
trunk version looks quite different. It is likely there will be a merge
conflict here.
Jan D.
Roy Liu skrev 2011-01-20 03.48:
> I've noticed that Emacs.app opens up relative pathnames twice -- once for the
> actual file, and once for the relative pathname appended to the directory of
> the current buffer.
> For example, trying to open by "a/b/text.txt" opens "a/b/text.txt" and
> attempts to open "a/b/a/b/text.txt".
>
> I wonder if the following patch corrects the problem:
>
> --- lisp/term/ns-win.el.orig 2010-12-12 23:31:04.000000000 -0500
> +++ lisp/term/ns-win.el 2010-12-12 23:32:00.000000000 -0500
> @@ -785,7 +785,7 @@
> "Do a `find-file' with the `ns-input-file' as argument."
> (interactive)
> (let ((f) (file) (bufwin1) (bufwin2))
> - (setq f (file-truename (car ns-input-file)))
> + (setq f (file-truename (expand-file-name (car ns-input-file)
> command-line-default-directory)))
> (setq ns-input-file (cdr ns-input-file))
> (setq file (find-file-noselect f))
> (setq bufwin1 (get-buffer-window file 'visible))
>
> Here, the input filename is expanded according to the current working
> directory when Emacs was invoked. Since I'm no expert, I don't know if this
> breaks something else.
>
> Thanks for your time!
>
[Message part 3 (message/rfc822, inline)]
[Message part 4 (text/plain, inline)]
Package: emacs
Version: 23.2
I've noticed strange loading behavior for Emacs.app when I wrap it with a
script:
#!/bin/bash
/Applications/MacPorts/Emacs.app/Contents/MacOS/Emacs "$@"
Here are my observations:
1) For files specified with --find-file and --find and --visit, loading goes
fine.
2) For files specified with absolute paths, loading is also fine.
3) For files specified with relative pathnames, things start getting weird.
For example, loading "a/b/c/d.txt" will load the desired file, but it will
then try to load "a/b/c/a/b/c/d.txt", which clearly doesn't exist. It's as
if directory "a/b/c" has been added to some sort of search path (in addition
to $PWD) in which emacs then relatively searches for "a/b/c/d.txt", thus
resulting in the joined result "a/b/c/a/b/c/d.txt".
I don't know if this should be a bug, since the desired usage of Emacs.app
is to run through the window manager (some form of "open"), which is a
sheltered environment.
I've built Emacs.app from MacPorts, which, from what I can tell, introduces
no special modifications or patches, and so I believe that this defect is
repeatable.
-Roy
[Message part 5 (text/html, inline)]
This bug report was last modified 14 years and 86 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.