GNU bug report logs - #7872
Possible fix for relative pathnames given through the command line

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#7872: closed (Possible fix for relative pathnames given
 through the command line)
Date: Wed, 26 Jan 2011 17:59:02 +0000

[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 Possible fix for relative pathnames given through the command line
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)]

From: Roy Liu <carsomyr <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Possible fix for relative pathnames given through the command line
Date: Wed, 19 Jan 2011 21:48:56 -0500

[Message part 3 (text/plain, inline)]

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 4 (text/html, inline)]

[Message part 5 (message/rfc822, inline)]

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Roy Liu <carsomyr <at> gmail.com>
Cc: 7872-done <at> debbugs.gnu.org
Subject: Re: bug#7872: Possible fix for relative pathnames given through the
	command line
Date: Wed, 26 Jan 2011 19:06:34 +0100

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!
>

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.