Re: printf %<n>s in UTF-8 is not always POSIX-compliant

[Peter Stephenson <Peter.Stephenson@csr.com>]

On Wed, 15 Feb 2012 00:14:12 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> The reason it's different for "emulate sh" is that sh emulation turns
> off all support for multibyte characters (unsetopt multibyte).  If you
> were to do
> 	emulate sh -c 'setopt multibyte; printf ".%2s.\n" é'
> then I believe you'd see the same behavior as with "emulate ksh".
> 
> As to whether it's correct ... I think I'd prefer the logical rather
> than literal interpretation, but it'll be difficult [or a hack that
> requires looking at the global emulation state, so it won't be possible
> to reproduce it with plain setopts] to turn off multibyte processing in
> printf for ksh emulation but not native zsh.

This sounds correct... We've never promised ksh mode would be a complete
representation of ksh anyway.  I realise that, for historical reasons
related to standards rather than zsh, you'd expect ksh mode to be POSIX
compatible, but actually we don't tend to bother because ksh mode isn't
that widely used and so doesn't get a lot of attention (I certainly
never use it).  If you really want compatibility native zsh mode or sh
mode are the sensible choices.

So probably the fix is to spread fear, uncertainty and doubt about ksh
mode.  I'll start right now.

If there is a hard-core ksh mode user who'd like to maintain it, of
course, that's another story.

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog