bug#23186: closed (Re: bug#23186: 25.0.92; Tramp: Windows does not always set COMSPEC, tramp blows up in a string-match)

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: ja2038@gmail.com,  23186@debbugs.gnu.org
> Date: Sun, 03 Apr 2016 17:55:29 +0200
> 
> > Can you (Michael) explain why does Tramp need this variable, and also
> > why it needs the companion tramp-encoding-command-switch?  Why not
> > just use shell-file-name and shell-command-switch?  Or, if you must
> > look deeper, why not call w32-shell-name or w32-shell-dos-semantics?
> > I think these already do what you need tramp-encoding-shell for, but
> > maybe I'm missing something.
> 
> Well, this is set this way for decades. I don't remember the datails;
> likely it was used also for other cases than just local encoding/
> decoding. And don't forget, Tramp has carried a lot of compat code, back
> to Emacs 21 and XEmacs. Maybe it was not possible to trust on 
> `w32-shell-name'.

I figured it was something like that.

> This compat code has been removed recently. So it is applicable indeed,
> to use `w32-shell-name'. I've committed a patch to master, doing this. I
> don't know, whether the setting for `tramp-encoding-command-switch' is
> OK, 'tho.

The beauty of w32-shell-name is that you don't need to worry about the
switch: cmdproxy supports both -c and /c (and even -C and /C).  So you
can now safely use just "-c" for tramp-encoding-command-switch.

Or, if you want to be extra-cautious, and protect Tramp from people
who point shell-file-name or $SHELL at something weird, you can use
w32-shell-dos-semantics: if it returns non-nil, use /c, otherwise -c.

> As usual, I cannot test it for w32. Let's see, whether we get reports :-)

Yep.

Thanks.