[PATCH] Fix '\%o' for printf from coreutils

[PATCH] Fix '\%o' for printf from coreutils

[Kacper Kornet]

The printf utility provided by coreutils when interpreting '\%o' format
does not recognize %o as formatting directive. For example
printf '\%o 0 returns \%o and warning: ignoring excess arguments,
starting with ‘0’, which results in failed tests in
t5309-pack-delta-cycles.sh. In most shells the test ends with success as
the printf is a builtin utility.

Fix it by using '\\%o' which is interpreted consistently in all versions
of printf.

Signed-off-by: Kacper Kornet <draenog@pld-linux.org>
---

I've found it while testing v1.8.5-rc0 with mksh which does not
provide a builtin printf.

Kacper

 t/lib-pack.sh | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/t/lib-pack.sh b/t/lib-pack.sh
index 7e8685b..b96e125 100644
--- a/t/lib-pack.sh
+++ b/t/lib-pack.sh
@@ -12,10 +12,10 @@
 # Print the big-endian 4-byte octal representation of $1
 uint32_octal () {
 	n=$1
-	printf '\%o' $(($n / 16777216)); n=$((n % 16777216))
-	printf '\%o' $(($n /    65536)); n=$((n %    65536))
-	printf '\%o' $(($n /      256)); n=$((n %      256))
-	printf '\%o' $(($n           ));
+	printf '\\%o' $(($n / 16777216)); n=$((n % 16777216))
+	printf '\\%o' $(($n /    65536)); n=$((n %    65536))
+	printf '\\%o' $(($n /      256)); n=$((n %      256))
+	printf '\\%o' $(($n           ));
 }
 
 # Print the big-endian 4-byte binary representation of $1
-- 
1.8.4.2

-- 
  Kacper Kornet

Re: [PATCH] Fix '\%o' for printf from coreutils

[Jeff King]

On Thu, Oct 31, 2013 at 12:51:32PM +0100, Kacper Kornet wrote:

> The printf utility provided by coreutils when interpreting '\%o' format
> does not recognize %o as formatting directive. For example
> printf '\%o 0 returns \%o and warning: ignoring excess arguments,
> starting with ‘0’, which results in failed tests in
> t5309-pack-delta-cycles.sh. In most shells the test ends with success as
> the printf is a builtin utility.
> 
> Fix it by using '\\%o' which is interpreted consistently in all versions
> of printf.

Thanks, this makes sense. POSIX says:

     [description of \n, \r, etc...]
     The interpretation of a backslash followed by any other
     sequence of characters is unspecified.

so we were wrong to rely on an unknown backslash-escape
being left alone. A quick grep seems indicate that this is
the only spot with the problem.

-Peff