bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

UTF-8-MAC completion 13 bytes away from being perfect


From: guillaume . outters
Subject: UTF-8-MAC completion 13 bytes away from being perfect
Date: Wed, 6 Jan 2010 00:04:41 +0100 (CET)

Configuration Information [Automatically generated, do not change]:
Machine: powerpc
OS: darwin8.11.0
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='powerpc' 
-DCONF_OSTYPE='darwin8.11.0' -DCONF_MACHTYPE='powerpc-apple-darwin8.11.0' 
-DCONF_VENDOR='apple' -DLOCALEDIR='/usr/local/bash-4.1.0/share/locale' 
-DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -DMACOSX   -I.  -I. -I./include 
-I./lib   -g -O2
uname output: Darwin asterix.local 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 
10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc
Machine Type: powerpc-apple-darwin8.11.0

Bash Version: 4.1
Patch Level: 0
Release Status: release

Description:
        Completion on accented filenames in Mac OS X works nicely now (and I 
find the hook a very elegant solution!). Well, except in a two-stage 
completion: after first completion attempt, any accents added by readline's 
completion breaks subsequent completions.

Repeat-By:
        Have directory perso containing a Délires and a Débogage.
                > ls perso/Dé<tab>
                Délire/ Débogage/
        OK, so we add a "b" and try again to complete:
                > ls perso/Déb<tab>
                (-- no output --)

Fix:
        On lib/readline/complete.c, at line 2222, replace "entry->d_name" by 
"convfn".

Explanation:
        Keyboard input and bash internal handling are made in UTF-8 NFC. Mac 
OS X FS uses UTF-8 NFD.
        So, first "> ls" (coming from keyboard) is NFC. readline reads perso/, 
gets Délires and Débogage in NFD, transforms them with 
rl_filename_rewrite_hook to convfn. They are now in NFC, and match with the 
input line.
        So readline decides to output those matches, and replaces the input 
line by the longest common match. But in this replacement, it uses 
entry->d_name (NFD). So the input line is replaced with its NFD equivalent.
        Thus on the next completion, on "perso/Déb", input is composed of this 
broken "perso/Dé" in NFD, followed by our keyboard-input "b". This NFD string 
does not match anymore with perso/Débogage in NFC (FS NFD "Débogage" 
rewritten by rl_filename_rewrite_hook).




reply via email to

[Prev in Thread] Current Thread [Next in Thread]