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 message dated Wed, 26 Jan 2011 19:06:34 +0100
with message-id <4D4062AA.6090601 <at> swipnet.se>
and subject line Re: bug#7872: Possible fix for relative pathnames given through the command line
has caused the GNU bug report #7872,
regarding OSX: Emacs.app is loading files specified by relative pathname twice
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> 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)]
[Message part 3 (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 4 (text/html, inline)]
[Message part 5 (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!
>
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.