On Sun, Feb 20, 2022 at 03:45:37PM +0200, Eli Zaretskii wrote: > > > > I do not think that it is a good solution either. On Linux, unless I > > missed something, the file name encoding should be utf-8 irrespective of > > the locale, or the Texinfo document encoding. > > No, that's incorrect. Linux filesystems don't care about the > file-name encoding, so any byte sequence will do; it just assigns > special meanings to 2 bytes: the null byte and the slash. > > However, most users specify file names in the locale's encoding, > because otherwise they might be unable to see them correctly, type > them on the keyboard, etc. And since most users use UTF-8 as the > locale's codeset, you get the effect that you thought is enforced by > the filesystem; it isn't.
It is not enforced by the filesystem, but I was under the impression that the tools used utf-8. I actually tested, and you are right, the locale seems to be a better default. If there is no encoding found with the locale, utf-8 can probably be used as a default. > On Windows, file names on disk are actually encoded in UTF-16 > (assuming NTFS filesystem). However, since makeinfo and Perl are > console programs, their Windows builds can generally only use the > single-byte encoding of the locale (the so-called "system codepage"); > Widows file-related API calls, like 'open', 'rename', 'delete', etc., > convert the locale-encoded file names into UTF-16 internally. Ok. > > In any case, I do not think that letting the user specify the file-name > > encoding would be any good, we should manage to get it right. > > The next best solution is IME to use the locale's codeset. There probably will be a customization variable anyway, but we really should not need to have to use it. -- Pat
