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

[Jim Porter]

On Thu, Jul 1, 2021 at 6:12 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Michael Albinus <michael.albinus@gmx.de>
> > Date: Thu, 01 Jul 2021 14:26:08 +0200
> > Cc: Jim Porter <jporterbugs@gmail.com>, 49283@debbugs.gnu.org
> >
> > 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.
>
> encode_current_directory returns an encoded file name.  So if we make
> this change, we should avoid calling ENCODE_FILE on it (doing so is a
> no-op, but it's still unclean).

I'd considered that when writing my initial patch to `call-process',
but I wasn't sure what the most-correct way to avoid that would be. It
seems we want an encoded path before returning from
`encode_current_directory' in order to check that our result is
actually accessible. But then that encoded dir gets passed in to
`expand-file-name'. If INFILE is an un-encoded absolute path, wouldn't
`expand-file-name' be un-encoded as well?

Maybe a better way would be to get the cwd *without* encoding it (see
the attached patch). However, maybe there's a simpler answer to all of
this that I just don't know about since I'm not very familiar with how
Emacs encodes file names.

0001-Ensure-call-process-interprets-infile-as-a-local-pat.patch
Description: Binary data