Anthony J. Bentley wrote: > Stefan Sperling writes: > > On Mon, Oct 26, 2015 at 03:58:58PM -0600, Anthony J. Bentley wrote: > > > "Ted Unangst" writes: > > > > it only gets deeper and thicker... > > > > > > Indeed. > > > > > > Here's a shorter implementation. Like colorls(1), it uses wide > > > characters (only within the putname() function) but is slightly cleaned > > > up and simplified. > > > > Is it really shorter if you follow the libc code paths this is calling? > > No, it's not. But that's not inherent to wchar_t, only to the Citrus > stuff that infests our libc. As Citrus gets cleaned up, this works > better instantly. And if we instead come up with better functions for > doing this kind of thing:
Fixing citrus is a pretty massive effort in itself. I'd prefer to see the replacement code prove itself as a separate API first, then we can remove citrus and change the wchar functions to use the new code. I'm less confident in a "meet in the middle" effort where we convert to wchar while simultanesouly hoping the wchar code gets better. In the mean time, maybe we should also look at a few more utilities. We seem to have some intuition that mbwidth() etc. will be useful, and maybe mbvis(), but we don't really know. So far I've poked at ul, rs, and ls. Then we've gone around in circles polishing those particular turds, but not much effort was spent looking at other utilities. What about wc? file? du? top? cut? vis??? Will adding utf-8/unicode support to each of those look the same? Or will every utility be different? Theo probably converted 100 utilities to use pledge before anything was committed to the tree. At the current rate, utf-8 will take another 10 years before anything happens. Additionally, I think all diffs to fix ls should be accompanied by before and after ktrace output. :)
