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

Previous Next

Full log

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] 27.2; `(call-process "program" null-device ...)' fails over
 TRAMP from local MS Windows
Date: Tue, 29 Jun 2021 22:14:19 -0700

[Message part 1 (text/plain, inline)]

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.

[0001-Ensure-call-process-interprets-infile-as-a-local-pat.patch (application/octet-stream, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.