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 #17 received at 49283 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Jim Porter <jporterbugs <at> gmail.com>, 49283 <at> debbugs.gnu.org
Subject: Re: bug#49283: [PATCH] 27.2; `(call-process "program" null-device
 ...)' fails over TRAMP from local MS Windows
Date: Thu, 01 Jul 2021 14:26:08 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

Hi,

>> 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.
>
> But is that what your first patch does?
>
> * 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);

Yes, this seems TRT. encode_current_directory returns either
default-directory if this is a local dir, or "~" otherwise. Expanding
INFILE to that directory is OK, I believe.

So we shall apply Jim's patch. Maybe the docstring could be enhanced a
little bit at the end, saying that INFILE, if it is a relative file
name, is expanded to the directory the process uses as cwd.

Previous Next

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