[Emacs-bug-tracker] bug#6179: closed (OSX: Emacs.app is loading files specified by relative pathname twice)

[GNU bug Tracking System]

Your message dated Wed, 26 Jan 2011 19:06:34 +0100
with message-id <address@hidden>
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
address@hidden)


-- 
7872: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7872
GNU Bug Tracking System
Contact address@hidden with problems

--- Begin Message --- Subject: OSX: Emacs.app is loading files specified by relative pathname twice Date: Wed, 12 May 2010 19:46:29 -0700 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

--- End Message ---

> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: bug#7872: Possible fix for relative pathnames given through the	command line
>
>
>
>
> Date: 
>
> Wed, 26 Jan 2011 19:06:34 +0100
>
>
>
>
> User-agent: 
>
> Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE;	rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
>
>
>
>
> 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!
>
>
> --- End Message ---