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: Mon, 03 Feb 2014 09:06:33 -0500
> 
> >> I'm having trouble understanding the above: can you give an example of
> >> a file which is neither absolute nor relative to the directory passed
> >> to the system API?
> > I think it happened to me with shr.el, since it doesn't set the
> > current directory of the buffer where it renders an HTML document.
> 
> Sounds like a bug in the code that extracts the name from the buffer and
> passes it to w32-shell-execute, or in the code that (fails to) set the
> buffer's default-directory.
> IOW the same would happen under GNU/Linux passing that file to call-process.
> 
> Or is there something different going on?
> 
> > In any case, this is not worse than what happened before the change
> > that introduced the call to expand-file-name: then, the ShellExecute
> > API was always called with a file name as passed to w32-shell-execute.
> 
> I guess the question for me now is "why call Fexpand_file_name"?
> I see it was introduced in:
> 
>   timestamp: Tue 2013-12-24 19:21:06 +0200
>   message:
>     Minor fixes in w32-shell-execute.
>   
>      src/w32fns.c (Fw32_shell_execute): Ensure DOCUMENT is an absolute
>      file name when it is submitted to ShellExecute.  Simplify code.
>      Don't test DOCUMENT for being a string, as that is enforced by
>      CHECK_STRING.  Doc fix.
> 
> But I don't know which problem it was trying to solve.

The problem happened when using a function in shr.el that no longer
exists.  To recreate that, I'd need to restore that function and trace
through that.  The result I do remember: w32-shell-execute failed
because DOCUMENT was a non-absolute file name, but not in the
directory where the function expected it to be.