Re: [Emacs-diffs] trunk r116230: Fix bug #16558 with w32-shell-execute on remote file names.

[Eli Zaretskii]

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