From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2514 invoked by alias); 12 Jun 2015 12:52:34 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 35451 Received: (qmail 5526 invoked from network); 12 Jun 2015 12:52:31 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, FREEMAIL_FROM,NML_ADSP_CUSTOM_MED,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS autolearn=no autolearn_force=no version=3.4.0 X-Injected-Via-Gmane: http://gmane.org/ To: zsh-workers@zsh.org From: Stephane Chazelas Subject: Re: printf, left-justification ignored in 5.0.8 Date: Fri, 12 Jun 2015 13:31:45 +0100 Message-ID: <20150612123145.GA6859@chaz.gmail.com> References: <20150607081142.GF15174@isis.sigpipe.cz> <30271.1433709564@thecus.kiddle.eu> <20150607211529.GA13370@chaz.gmail.com> <20150612113050.GA21806@ypig.lip.ens-lyon.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 05448b1b.skybroadband.com Content-Disposition: inline In-Reply-To: <20150612113050.GA21806@ypig.lip.ens-lyon.fr> User-Agent: Mutt/1.5.21 (2010-09-15) 2015-06-12 13:30:50 +0200, Vincent Lefevre: > On 2015-06-07 22:15:29 +0100, Stephane Chazelas wrote: > > BTW, there was a discussion lately on the Austin group mailing > > list confirming that the %20s should count bytes, not > > characters. > > > > That is in a UTF-8 locale > > > > printf '|%3s|\n' e é € > > > > should print: > > > > | e| > > | é| > > |€| > > > > not: > > > > | e| > > | é| > > | €| > > > > I find the zsh behaviour more useful though, > > Well, it depends on the context. As I've said in > > http://www.zsh.org/mla/workers/2012/msg00151.html > > Yes, the number is the size in bytes, not in characters. I think > that the intent is to deal with internal structures (e.g. with > file formats where some fields have a fixed or limited size, and > the same syntax can be used in C to avoid buffer overflows). > > I don't know if this is the real reason. I beleive the real reason was to align on C printf (not wprintf for instance) (makes little sense to me) > > especially considering that in zsh we can get the POSIX behaviour > > with: > > > > $ LC_ALL=C printf '|%3s|\n' e é € > > | e| > > | é| > > |€| > > However the change of locale may affect other format specifiers, > like %f, and error messages. Well, that's a general problem with LC_* handling. Here however it can be worked around by using several invocations of printf. [...] > > ksh93 has %3Ls for that: > > > > $ printf '|%3Ls|\n' e $'\ue9' $'e\u301' $'\uff45' > > | e| > > | é| > > | é| > > | ｅ| > > > > (possibly uses wcswidth()). > > This could be useful in zsh, and its support would be needed for > "emulate ksh". [...] While I agree that could be useful feature, note that zsh is not (and will never be I hope) a superset of ksh93. The emulation mode changes some behaviour that othewise differ from ksh. It covers mostly ksh88, and zsh has a few features from ksh93 but that's about it. -- Stephane