2012/2/17 Vincent Lefevre <vincent-svn_at_vinc17.net>:
> On 2012-01-30 21:29:41 +0100, Stefan Sperling wrote:
>> On Mon, Jan 30, 2012 at 09:09:22PM +0100, Branko Čibej wrote:
>> > Are you seriously proposing that we /support/ such broken, hackish
>> > nonsense? How do you expect users to tell the difference between file
>> > names that look identical on the character level, but are not on the
>> > code point level?
>> >
>> > Supporting such hacks would only be a source of bug reports. I don't see
>> > this as a desirable feature.
>>
>> The question is why you would want to break it now that it works.
>> Because of HFS+? [...]
>
> I think you mean because of Mac OS X. Indeed, unless this has changed,
> with the Mac OS X Terminal, when a user types an accented character,
> it is in NFD at the command line level. So, even if the user uses a
> conventional file system that can store both NFC and NFD, the filename
> will be in NFD, which will annoy Linux users.
Actually, whether filename is in NFC or NFD depends on the way of
inputting filenames.
If you type all characters, it is in NFC.
If you use shell filename completion by hitting tab key, it is in NFD.
I tried with Japanese filenames and confirmed this.
So, it is HFS+ which returns the filenames in NFD.
--
)Hiroaki Nakamura) hnakamur_at_gmail.com
Received on 2012-02-17 05:55:15 CET