[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#49283: [PATCH] 27.2; `(call-process "program" null-device ...)' fail
From: |
Jim Porter |
Subject: |
bug#49283: [PATCH] 27.2; `(call-process "program" null-device ...)' fails over TRAMP from local MS Windows |
Date: |
Tue, 29 Jun 2021 22:14:19 -0700 |
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
Description: Binary data
- bug#49283: [PATCH] 27.2; `(call-process "program" null-device ...)' fails over TRAMP from local MS Windows,
Jim Porter <=