bug#24387: 25.1.50; w32-convert-standard-filenames no longer works

[Richard Copley]

On 7 September 2016 at 15:26, Eli Zaretskii <eliz@gnu.org> wrote:
> retitle 24387 w32-convert-standard-filenames no longer mirrors slashes
> thanks
>
>> From: Richard Copley <rcopley@gmail.com>
>> Date: Wed, 7 Sep 2016 10:52:32 +0100
>>
>> commit 438b98e5b70c55129453870b870a139c4a4a77fd
>> Author: Eli Zaretskii <address@hidden>
>> Date:   Mon Apr 25 11:50:37 2016 +0300
>>
>>     Don't mirror slashes in convert-standard-filename on MS-Windows
>>
>>     * lisp/w32-fns.el (w32-convert-standard-filename): Don't mirror
>>     slashes into backslashes.  This avoids producing ugly file names,
>>     and is deemed no longer necessary, and should certainly be
>>     unrelated to which shell is in use.
>>
>> I for one /did/ use filenames created by this function in shell
>> commands.
>
> Why did you do that?  It's a mistake: that function's purpose is
> entirely different, as the ELisp manual documents:
[...]
> IOW, this function is for Lisp programs that need to specify a fixed
> standardized file name.  It has no relation whatsoever to shell
> commands.

I see, thanks.

>> It was explicitly documented that it would work,
>> and it still is (see the docstring for `convert-standard-filename').
>
> Oops!  Will fix, thanks.
>
>> Now I need to take time out to roll my own version and review
>> all my callers
>
> Do you really need to mirror slashes in shell commands?

I do. I only investigated this because stuff stopped working.

> Most Windows
> applications understand forward slashes just fine.

I know; this is for the shell itself, so it's generally only for the names of
and/or paths to program files.

> What problems do
> you have with forward slashes in shell commands on MS-Windows?

I didn't go into detail because it's not all that interesting.
In fact I sometimes modify `exec-path' at runtime (in a fairly controlled
manner, but it's not something I'd inflict on other users); for the sake
of subprocesses, I also set the PATH environment variable in Emacs
correspondingly, using `convert-standard-filename' and `path-separator'
(the intention was to be cross-platform, as I have the same site-lisp
and init.el checked out in various places). This of course has drawbacks;
those are not your problem!

The symptom was that vc-pull stopped working if Windows git needed to
invoke MSYS ssh during `vc-pull' (git was "unable to spawn ssh"),
so there was another layer of translation involved too, which might also
have been where things went wrong.

>> Please will you change it back?
>
> That would bring back the ugliness I fixed by the commit in question.
> And the use case for which you want the feature is simply wrong, you
> are not supposed to use convert-standard-filename for such purposes.

Fair enough.

>> If not, when that docstring gets fixed, can it document what people
>> should use instead?
>
> I'm not sure what to say in the doc string.  On the one hand, the
> function is not to be used in preparation of shell commands, so
> talking about shell commands there would be wrong, IMO.  OTOH,
> replacing one character with another is a trivial operation in Emacs,
> something like
>
>         (setq start 0)
>         (while (string-match "/" name start)
>           (aset name (match-beginning 0) ?\\)
>           (setq start (match-end 0))))
>
> should be all you need.
>
> I could add the above snippet to the NEWS entry that announces the
> change; would that be good enough?

Up to you; if you want to help out other people who made the same
mistake, I expect they'd appreciate it.

The function `cygwin-convert-file-name-to-windows' exists.
Maybe you'd consider including that function(ality) in non-cygwin
builds, with an alias ((w32-)convert-file-name-to-windows?). It could
be documented in the same footnote; I think that's where it would be
easiest to discover.

Either way I accept your explanation and I will fix my code.

Thanks,
Richard.