From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <5597aeb2af08782d984e2a59b4c6775d@brasstown.quanstro.net> References: <5597aeb2af08782d984e2a59b4c6775d@brasstown.quanstro.net> Date: Sat, 14 Sep 2013 11:51:09 +0200 Message-ID: From: Mark van Atten To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Subject: Re: [9fans] NFD and p9p acme on OSX Topicbox-Message-UUID: 7f94f7a4-ead8-11e9-9d60-3106f5b1d025 Thank you, Erik, for your comments! I just realized that in fn ls { builtin ls $* | iconv -f UTF8-MAC -t UTF-8 } one needs u iconv because otherwise it picks the wrong iconv when executing this redefined ls in contexts where $PLAN9/bin occurs in the path first; for example, try 9 man cat with the uncorrected redefinition of ls. As ever, Mark. On Thu, Sep 12, 2013 at 4:17 PM, erik quanstrom wrote: > On Thu Sep 12 05:41:19 EDT 2013, vanattenmark@gmail.com wrote: >> Running p9p on OSX, I find it useful to put this in my rc profile: >> >> fn ls { >> builtin ls $* | iconv -f UTF8-MAC -t UTF-8 >> } >> >> fn lc { >> builtin lc $* | iconv -f UTF8-MAC -t UTF-8 >> } >> >> so as to deal with the NFD used by the OSX file system and list >> names containing non-ascii characters correctly. >> >> But this doesn't solve the corresponding problem when clicking B3 to >> open a directory in acme. >> >> Am I overlooking something? If not, what do people use to deal with >> this---perhaps a patch to lib9? > > i created something similar for plan 9. it uses runecompose > (see runeclass(2), http://9atom.org/magic/man2html/2/runeclass) > this uses tables built by awk scripts directly from unicodedata.txt. > there is a rune/compose (see rune(1), http://9atom.org/magic/man2html/1/rune) > that makes it possible to write > fn lc {builtin lc $* | rune/compose} > > but i agree, one would like a more systemic solution. cooking this > into stat/wstat wouldn't work, because the file name text might escape > p9p and cause the rest of the system to be confused. > > perhaps runecompose and runedecompose (or equivalent) could be > cooked into fullrune, chartorune, runetochar, etc. (for apple oses only?) > the big pain point would be dealing with the fact that chartorune > could create up to maxcombiners*4 bytes of utf-8, and fullrune might > need that size buffer to convert one rune. it's easy to grep for these > use cases. > > - erik >