Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: printf %s in UTF-8 is not POSIX-compliant
- X-seq: zsh-workers 24678
- From: Peter Stephenson <pws@xxxxxxx>
- To: zsh-workers@xxxxxxxxxx
- Subject: Re: printf %s in UTF-8 is not POSIX-compliant
- Date: Tue, 04 Mar 2008 09:40:07 +0000
- In-reply-to: <20080304012917.GA15833@xxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <20080304012917.GA15833@xxxxxxxxxxxxxxxxxxx>
Vincent Lefevre wrote:
> Under UTF-8 locales:
>
> vin:~> zsh-beta -f
> vin% emulate sh
> vin% printf ".%2s.\n" é
> . é.
> vin% /usr/bin/printf ".%2s.\n" é
> .é.
> vin%
>
> As you can see, the zsh printf builtin doesn't behave like the
> coreutils printf, and this is zsh which is wrong. Indeed, the
> precision is the number of bytes, not the number of characters.
That seems to me useless. I can understand in C that a string is a
low-level entity consisting of a set of bytes, but I don't see why a
shell should force the user to count the size of a multibyte character
in the particular locale.
You can fix it by unsetting the MULTIBYTE option.
printf() { emulate -L zsh; unsetopt multibyte; builtin printf "$@" }
--
Peter Stephenson <pws@xxxxxxx> Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070
Messages sorted by:
Reverse Date,
Date,
Thread,
Author