Re: [l...@ecentrum.hu: Re: ls(1) multibyte support]
On Thu, Mar 22, 2012 at 12:24:28 +0100, Stefan Sperling wrote: On Thu, Mar 22, 2012 at 11:18:43AM +0100, Peter Hessler wrote: from what I can tell, the problems blocking this diff from going in have been fixed, and it looks good to me. [...] For now, if you really require multi-byte filenames in ls output you can install colorls and alias it to 'ls' in your shell. Thank You for the answer and the suggestion. I'm going to use colorls; it is even a bit less hassle to install colorls than to sync, patch, install src/bin/ls on every -current update. Daniel -- LIVAI Daniel PGP key ID = 0x83B63A8F Key fingerprint = DBEC C66B A47A DFA2 792D 650C C69B BE4C 83B6 3A8F
Re: ls(1) multibyte support
On Tue, Jan 04, 2011 at 09:14:51PM +0300, Alexander Polakov wrote: Hi, I wonder if there any plans on adding multibyte support for ls(1)? Or maybe there's a reason why it's not a great idea (which I am not aware of)? Anyway, here's a patch I have. It's based on DragonFlyBSD's ls. Any locale stuff added to applications that are used on the ramdisk (bsd.rd) must be inside #ifndef SMALL. The ls binary is linked statically so we need to prevent it from wasting space by pulling citrus stuff onto the ramdisk. More importantly, there is an alleged bug in our wcwidth() implementation. I haven't had time to investigate, but it has been pointed out on separate occasions, by Jordi Beltran Creix and by nicm@. Test program (from Jordi): Hi! Any plans of committing this? [1] I've been using these diffs for quite some time now, and it is really convenient and great to see the utf-8 filenames properly in ls' output. [1]: http://marc.info/?l=openbsd-techm=129416906310823w=2 Dani -- LIVAI Daniel PGP key ID = 0x83B63A8F Key fingerprint = DBEC C66B A47A DFA2 792D 650C C69B BE4C 83B6 3A8F
Re: [l...@ecentrum.hu: Re: ls(1) multibyte support]
On Thu, Mar 22, 2012 at 11:18:43AM +0100, Peter Hessler wrote: from what I can tell, the problems blocking this diff from going in have been fixed, and it looks good to me. (Putting misc@ on Cc so that everyone interested gets this information.) There is more to this than the wcwidth() bug (which, yes, has been fixed). There are general open questions as to how much support for wide characters the base system should get. If we modify ls(1), which other tools do we also modify? What rules do we apply when adding wide character support to one tool but not another? How do we guarantee that all base tools behave consistently with multi-byte characters? Changing all base tools to use wide characters is not a very satisfying answer. It is a lot of work and will cause a lot of code churn in base. With ports, the story is different. These are intended to provide functionality the base system doesn't offer. A lot of applications in ports already provide wide-character support. The base system now offers most of the necessary library support to those applications. During s2k11 I added wide-char support to the sysutils/colorls port. This is OpenBSD's ls, with some patches to add color support, and now also multi-byte support. For now, if you really require multi-byte filenames in ls output you can install colorls and alias it to 'ls' in your shell.
