Hi Ingo, On Tue, May 30, 2017 at 2:28 AM, Ingo Schwarze <schwa...@usta.de> wrote:
> Walter Alejandro Iglesias wrote on Mon, May 29, 2017 at 06:44:40PM +0200: > >> Are those wide char versions of C functions consistent enough to write >> a separate implementation to be loaded when LC_TYPE is set to utf-8? > > Sure, you can rewrite the complete shell to use wchar_t * rather > than char *, and if you do that, you can use the new code to handle > ASCII as well, no need to have two copies. But that would be a > huge effort, even more error-prone than the small, careful adjustments > we are doing now, and would have a number of additional downsides; > among others, losing the ability to handle arbitrary bytes, while > in UTF-8 mode. You are right. With wchar_t, you could avoid isu8cont() and other dirty hacks, but you might face much more troubles. I have a joke diff for ksh: https://pastebin.com/HC48zS1q In fact, I didn't figure out why my diff didn't show what I typed, while Ctrl-L worked. ;) Multibyte is simply crazy if you have to calculate the width. I don't want /bin/sh to be a complete multibyte shell. When I need a multilingual shell, I use other shells like zsh. The current implementation of ksh has a perfect balance between complexity and usefulness. Thanks, tamo
