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

Previous Next

Full log

View this message in rfc822 format

From: Jim Porter <jporterbugs <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 49283 <at> debbugs.gnu.org
Subject: bug#49283: [PATCH] 27.2; `(call-process "program" null-device ...)' fails over TRAMP from local MS Windows
Date: Wed, 30 Jun 2021 10:16:28 -0700

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

On Wed, Jun 30, 2021 at 12:24 AM Michael Albinus <michael.albinus <at> gmx.de> wrote:
>
> Jim Porter <jporterbugs <at> gmail.com> writes:
>
> > 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'.
>
> `call-process' doesn't know of remote files. You must use `process-file' instead.

That's not a problem; it's actually the right thing to do in this
case, I think. flyspell/ispell is trying to use my local version of
hunspell on the contents of a remote buffer. Since flyspell/ispell
just look at the buffer contents and not the actual file, it can use
`call-process'.

> It is not a good idea to use `null-device' as INFILE, just use nil. At
> least in the `process-file' case, Tramp shall know which value to take
> for `null-device'.

That fix would also work (see the attached patch).

However, when I read the `call-process' documentation, it says that
when `default-directory' is remote, it runs the program from "~".
That's fine overall, and means it's a good way to be sure you're
always running a process locally. It's just that when you do this,
INFILE's path is expanded relative to the remote directory. I don't
think that can ever work, since `call-process' doesn't know how to
open a TRAMP file. Because of that, it makes more sense to me that
you'd expand INFILE's path relative to wherever PROGRAM will be run
from. That means that when `default-directory' is remote, both PROGRAM
and INFILE are expanded relative to "~". That's more consistent, and
my first patch would hopefully prevent similar errors anytime
`call-process' is used from a remote buffer.

[0001-Don-t-pass-null-device-to-call-process-in-ispell.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.