all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Jim Porter <jporterbugs@gmail.com>
To: Michael Albinus <michael.albinus@gmx.de>
Cc: 49283@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	[thread overview]
Message-ID: <CANh=_JHiSwX9ttyw4zjTwMgbCmp9Cj=aq=GooFVm7WCO-M0Jsg@mail.gmail.com> (raw)
In-Reply-To: <87a6n7zuf4.fsf@gmx.de>

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

On Wed, Jun 30, 2021 at 12:24 AM Michael Albinus <michael.albinus@gmx.de> wrote:
>
> Jim Porter <jporterbugs@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.

[-- Attachment #2: 0001-Don-t-pass-null-device-to-call-process-in-ispell.patch --]
[-- Type: application/octet-stream, Size: 915 bytes --]

From 2eee9b4e70fe489eb46fb94ab000c6d0b7262e28 Mon Sep 17 00:00:00 2001
From: Jim Porter <jporterbugs@gmail.com>
Date: Wed, 30 Jun 2021 10:01:32 -0700
Subject: [PATCH] Don't pass 'null-device' to 'call-process' in ispell

* lisp/textmodes/ispell.el (ispell-find-hunspell-dictionaries):
Replace 'null-device' with nil.
---
 lisp/textmodes/ispell.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/textmodes/ispell.el b/lisp/textmodes/ispell.el
index ce5a572085..0a82bf5a2d 100644
--- a/lisp/textmodes/ispell.el
+++ b/lisp/textmodes/ispell.el
@@ -1076,7 +1076,7 @@ ispell-find-hunspell-dictionaries
           (split-string
            (with-temp-buffer
              (ispell-call-process ispell-program-name
-                            null-device
+                            nil
                             t
                             nil
                             "-D"
-- 
2.25.1


  reply	other threads:[~2021-06-30 17:16 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-30  5:14 bug#49283: [PATCH] 27.2; `(call-process "program" null-device ...)' fails over TRAMP from local MS Windows Jim Porter
2021-06-30  7:24 ` Michael Albinus
2021-06-30 17:16   ` Jim Porter [this message]
2021-07-01 11:07     ` Lars Ingebrigtsen
2021-07-01 12:26       ` Michael Albinus
2021-07-01 12:34         ` Lars Ingebrigtsen
2021-07-01 13:12         ` Eli Zaretskii
2021-07-01 19:45           ` Jim Porter
2021-07-02  6:37             ` Eli Zaretskii
2021-07-02 18:47               ` Jim Porter
2021-07-03  7:02                 ` Eli Zaretskii
2021-07-04 13:32                 ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CANh=_JHiSwX9ttyw4zjTwMgbCmp9Cj=aq=GooFVm7WCO-M0Jsg@mail.gmail.com' \
    --to=jporterbugs@gmail.com \
    --cc=49283@debbugs.gnu.org \
    --cc=michael.albinus@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.