Re: [9fans] NFD and p9p acme on OSX
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 quans...@quanstro.net wrote:
On Thu Sep 12 05:41:19 EDT 2013, vanattenm...@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
[9fans] NFD and p9p acme on OSX
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?
Mark.
Re: [9fans] NFD and p9p acme on OSX
On Thu Sep 12 05:41:19 EDT 2013, vanattenm...@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
