GNU bug report logs - #22803
bash printf and negative precision

Previous Next

Package: coreutils;

Reported by: "Billerbeck, Dirk" <dirk.billerbeck <at> dataport.de>

Date: Thu, 25 Feb 2016 09:47:02 UTC

Severity: normal

Tags: notabug

Done: Assaf Gordon <assafgordon <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Billerbeck, Dirk" <dirk.billerbeck <at> dataport.de>
To: "bug-coreutils <at> gnu.org" <bug-coreutils <at> gnu.org>
Subject: bash printf and negative precision
Date: Thu, 25 Feb 2016 07:18:24 +0000
[Message part 1 (text/plain, inline)]
Hello,

I don't know if it's really a bug, if I'm just mistaken or this is the right address but I just want to give it a try.

I'm using the following bash-builtin printf command:

FUELLLAENGE=8 ; report="REPIBZVAG" ; REPORTFUELLZEICHEN="0" ; printf '%.8s%*.*d\n' $report 0 $((FUELLLAENGE - ${#report} )) "$REPORTFUELLZEICHEN"

The maximum length of $report  is 8 characters but I tested some possible error situations so in this example it is 9 characters log. I would expect printf to cut the $report from REPIBVZAG to REPIBZVA and to NOT print any additional trailing zeros because of the precision value of -1. But a trailing zero is printed (set -x output):

+ FUELLLAENGE=8
+ report=REPIBZVAG
+ REPORTFUELLZEICHEN=0
+ printf '%.8s%*.*d\n' REPIBZVAG 0 -1 0
REPIBZVA0

Is this really correct? Or shouldn't the negative precision be taken as zero and no character should be printed?

The bash version is "GNU bash, version 3.2.51(1)-release (x86_64-suse-linux-gnu)". I know it's an older version but I can't change it as there are corporate restrictions. The coreutil package is "coreutils-8.12-6.25.32.33.1".

Best regards
Dirk Billerbeck
[Message part 2 (text/html, inline)]

This bug report was last modified 6 years and 290 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.