[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Emacs-diffs] trunk r116230: Fix bug #16558 with w32-shell-execute o

From: Eli Zaretskii
Subject: Re: [Emacs-diffs] trunk r116230: Fix bug #16558 with w32-shell-execute on remote file names.
Date: Tue, 04 Feb 2014 23:01:17 +0200

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden
> Date: Tue, 04 Feb 2014 15:35:25 -0500
> > The problem that led me to introduce this call is that this succeeds:
> >   (w32-shell-execute "open" "file")
> > but this fails:
> >   (w32-shell-execute "open" "dir/file")
> > IOW, the DOCUMENT arg must either be an absolute file name, or live
> > inside default-directory, not in one of its subdirectories.
> Ah, that makes it more clear.  We should include this example in the comments.

Please see the new-and-improved commentary there.

> It does beg the question: what does
>    (w32-shell-execute "open" "dir/file")
> do, then?  You say it "fails", but does it signal an error?

Yes, it says the file was not found (a.k.a. ENOENT).

> If so, why?

Looks like a limitation of the OS API we use there.  The error code
comes directly from the API.

> My world view is very POSIX-centric, so I'm probably missing the obvious.

This API uses the "file association" infrastructure to find the
application registered to open a file.  Perhaps that infrastructure
cannot cope with relative file names that have leading directories?
That's a guess; the MS documentation doesn't say this clearly, which
is why this code was not written like that to begin with.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]