Jim Porter <jporterbugs@gmail.com> writes:

Hi Jim,

> Hopefully I've summarized the issue correctly in the bug title. To see
> this in action, run the following from `emacs -Q' on an MS-Windows
> system ("host" in this example is a remote GNU/Linux system):
>
>   C-x C-f /ssh:host:~
>   M-x rgrep RET
>   some text RET RET RET
>
> The rgrep output will look something like:
>
>   find [...] --null -e "some text" "{}" +
>   find: paths must precede expression: `^^!^'

I confirm the bug, it happens also for me.

> You can click the "[...]" to see the full invocation. However, even
> without doing that, if you look carefully, you'll notice that the
> shell-quoting uses the MS-Windows rules, not that of /bin/sh. For the
> MS-Windows shell, spaces are quoted by wrapping the entire argument in
> double-quotes ("like this"); for /bin/sh, spaces are escaped via a
> backslash (like\ this).
>
> Presumably, that's because if you eval `shell-file-name' in the Dired
> buffer, it reports ".../path/to/cmdproxy.exe". When in a remote
> *file*, `shell-file-name' is correctly set to "/bin/sh".

It is not a problem of shell-file-name, if you check the Tramp debug
buffer you'll see, that a proper shell ("/bin/sh" in my case) is
applied.

The problem is rather quoting the arguments with shell-quote-argument. It
applies the quoting according to the value of system-type. If this is
'ms-dos or 'windows-nt, MS Windows quoting rules are applied.

The appended patch fixes this for me, could you pls check?

Best regards, Michael.