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

Package:
zsh
Source:
zsh
Description:
shell with lots of features
Submitter:
Vincent Lefevre
Date:
2012-12-21 11:12:08 UTC
Severity:
normal
#659932#5
Date:
2012-02-15 02:10:20 UTC
From:
To:
In UTF-8 locales:

xvii% printf ".%2s.\n" é
. é.
xvii% emulate sh
xvii% printf ".%2s.\n" é
.é.
xvii% emulate ksh
xvii% printf ".%2s.\n" é
. é.

It is correct in sh mode (according to POSIX[*]), but not in ksh mode,
which should also follow the POSIX behavior. What about zsh mode?

[*] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/printf.html
and
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap05.html#tag_05
for %<n>s.
#659932#14
Date:
2012-12-20 22:09:52 UTC
From:
To:
Hi Vincent,

Vincent Lefevre wrote:

Reading the thread started by
http://www.zsh.org/mla/workers/2012/msg00149.html it seems as if this
issue was basically a follow-up error of http://bugs.debian.org/659969
which you reported on advise of upstream in that thread.

Hence this issue should be fixed with 5.0.0-1, too. If you disagree,
feel free to reopen the bug report. From what I read I though don't
expect this to be fixed in any other way by upstream.

		Regards, Axel
#659932#19
Date:
2012-12-21 11:03:25 UTC
From:
To:
reopen 659932
found 659932 5.0.0-2
thanks

659969 is about zsh being in ksh alternatives, but the bug still
exists for both ksh and zsh.

For ksh, a simple solution might be to replace the printf builtin
to do:
  1. Save the multibyte processing status.
  2. Disable multibyte processing (unsetopt multibyte).
  3. Execute the real printf builtin.
  4. Restore multibyte processing.

For zsh, if it is really intended to differ from C, this needs to be
documented. It is currently said:

    printf format [ arg ... ]
         Print the arguments according to the format specification.
         Formatting rules are the same as used in C. [...]

which is not the observed behavior.