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

[Lars Ingebrigtsen <larsi@gnus.org>]

Jim Porter <jporterbugs@gmail.com> writes:

>> 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).

Applied to Emacs 28 now.

> 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);



-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no