On Thu, Jul 1, 2021 at 11:37 PM Eli Zaretskii wrote: > > > From: Jim Porter > > Date: Thu, 1 Jul 2021 12:45:42 -0700 > > Cc: Michael Albinus , Lars Ingebrigtsen , 49283@debbugs.gnu.org > > > > 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? > > expand-file-name is not a problem, it can deal with encoded file > names. The problem is the calls to remove_slash_colon and > report_file_error: they should receive file names in their internal > representation. Right, I was just worried that if I relied on `encode_current_directory' returning an encoded path, `expand-file-name' might sometimes return an encoded path (e.g. if INFILE is a simple relative path like "foo") and sometimes an unencoded path (e.g. if INFILE is an absolute path). I might be wrong though, since I didn't look closely at the implementation... > How about adding a 'bool' argument to encode_current_directory, so > that the caller could control whether or not it encodes the directory > file name? Then you could in this case tell encode_current_directory > not to encode the directory file name. Ok, I did that (and renamed it to `get_current_directory' since it doesn't always encode anymore). How does the attached patch look?