[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#49283: [PATCH] 27.2; `(call-process "program" null-device ...)' fail
bug#49283: [PATCH] 27.2; `(call-process "program" null-device ...)' fails over TRAMP from local MS Windows
Thu, 1 Jul 2021 12:45:42 -0700
On Thu, Jul 1, 2021 at 6:12 AM Eli Zaretskii <firstname.lastname@example.org> wrote:
> > From: Michael Albinus <email@example.com>
> > Date: Thu, 01 Jul 2021 14:26:08 +0200
> > Cc: Jim Porter <firstname.lastname@example.org>, email@example.com
> > 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.
Description: Binary data