GNU bug report logs - #48902
28.0.50; Directory names containing apostrophes and backticks cause problems

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Third <alan <at> idiocy.org>
Cc: 48902 <at> debbugs.gnu.org, larsi <at> gnus.org, salutis <at> me.com, naofumi <at> yasufuku.dev
Subject: bug#48902: 28.0.50; Directory names containing apostrophes and backticks cause problems
Date: Tue, 08 Jun 2021 21:09:51 +0300

> Date: Tue, 8 Jun 2021 17:19:44 +0100
> From: Alan Third <alan <at> idiocy.org>
> Cc: larsi <at> gnus.org, naofumi <at> yasufuku.dev, 48902 <at> debbugs.gnu.org,
> 	salutis <at> me.com
> 
> In this case the call to ENCODE_FILE in allocInitFromFile is actually
> redundant because image_find_image_fd already calls ENCODE_FILE on the
> filename before passing it back. So we get a UTF-8 string no matter
> what.

Then why was the code re-encoding t in UTF-16?  A bug?

> NSString can read in almost anything, and Mattias extended it to read
> in multibyte (and ascii) lisp strings, so we don't need a UTF-16 input
> specifically. It would probably be nice if NSString was also able to
> recognise that a lisp string is UTF-8 and handle that itself, but I
> don't think that's really possible, unless we make the assumption that
> any unibyte string it's passed will already be ascii or UTF-8.
> 
> I don't know if that's a reasonable assumption.

Any file name passed through ENCODE_FILE should be in UTF-8 on macOS,
as I understand that's how the macOS filesystems work.  Am I mistaken?
Can the value of default-file-name-coding-system on macOS be anything
other than UTF-8?

Previous Next

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