bug#49283: [PATCH] 27.2; `(call-process "program" null-device ...)' fails over TRAMP from local MS Windows

[Jim Porter <jporterbugs@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2239 bytes --]

I noticed an issue when trying to use flyspell (or ispell) using
hunspell from a local MS Windows system on a TRAMP file. It results in
an error that it can't find the file "/sshx:server:/path/to/NUL". I
narrowed this down to the fact that
`ispell-find-hunspell-dictionaries' calls `call-process' with `infile'
set to `null-device'. To see this in action:

  emacs -Q
  C-x C-f /sshx:server:~/path/to/file.txt
  M-: (setq ispell-program-name "hunspell") RET
  M-x flyspell-mode
  ;; or...
  M-: (call-process "something" null-device) RET

This results in the following error:

----------------------------------------
Debugger entered--Lisp error: (file-missing "Opening process input
file" #("No such file or directory" 0 25 (charset windows-1252))
"/sshx:server:/path/to/NUL")
  call-process("something" "NUL")
  eval((call-process "something" null-device) t)
  eval-expression((call-process "something" null-device) nil nil 127)
  funcall-interactively(eval-expression (call-process "something"
null-device) nil nil 127)
  call-interactively(eval-expression nil nil)
  command-execute(eval-expression)
----------------------------------------

It seems this is a result of the fact that `null-device' on MS Windows
is "NUL", and `(expand-file-name "NUL")' is "<default-directory>/NUL".
When `default-directory' is a local MS Windows path, this is ok, but
when it's a TRAMP path, it looks for a real file named NUL on the
remote (GNU/Linux) machine. However, since `call-process' executes
from the (local) home directory if `default-directory' is a TRAMP
path, I think it makes more sense for `infile' to be interpreted
relative to the homedir too.

I've attached a speculative patch that I think fixes this. (Note: I
don't have an MS Windows build environment set up at the moment, so I
only tested that this works like I'd expect from GNU/Linux. It'd
probably be good to make sure it works on MS Windows too.)

While I'm hesitant to touch something as low-level as `call-process',
I think fixing this in general would be the best long-term solution,
assuming it doesn't break something I'm unaware of. Another,
less-invasive fix would be to fix `ispell-find-hunspell-dictionaries'
to pass `nil' as the `infile' when invoking hunspell.

[-- Attachment #2: 0001-Ensure-call-process-interprets-infile-as-a-local-pat.patch --]
[-- Type: application/octet-stream, Size: 903 bytes --]

From e737f400f7e57fc99222b5c351e4853735c2c6f4 Mon Sep 17 00:00:00 2001
From: Jim Porter <jporterbugs@gmail.com>
Date: Tue, 29 Jun 2021 22:01:53 -0700
Subject: [PATCH] Ensure 'call-process' interprets 'infile' as a local path

* src/callproc.c (Fcall_process): Interpret 'infile' relative to the
directory from which 'program' is called, not 'default-directory'.
---
 src/callproc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/callproc.c b/src/callproc.c
index aabc39313b..57cf781d28 100644
--- a/src/callproc.c
+++ b/src/callproc.c
@@ -270,7 +270,7 @@ DEFUN ("call-process", Fcall_process, Scall_process, 1, MANY, 0,
 
   if (nargs >= 2 && ! NILP (args[1]))
     {
-      infile = Fexpand_file_name (args[1], BVAR (current_buffer, directory));
+      infile = Fexpand_file_name (args[1], encode_current_directory ());
       CHECK_STRING (infile);
     }
   else
-- 
2.25.1