{"thread":{"id":"35256","subject":"[PATCH] Fix '\\%o' for printf from coreutils","startedAt":"2013-10-31T11:51:32Z","lastAt":"2013-10-31T16:49:21Z","messageCount":2,"participants":["Kacper Kornet","Jeff King"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"229916","messageId":"20131031115131.GA28379@camk.edu.pl","threadId":"35256","inReplyTo":null,"subject":"[PATCH] Fix '\\%o' for printf from coreutils","fromName":"Kacper Kornet","fromEmail":"draenog@pld-linux.org","sentAt":"2013-10-31T11:51:32Z","receivedAt":"2013-10-31T11:51:32Z","isPatch":true,"sender":{"key":"draenog@pld-linux.org","avatar":"https://avatars.githubusercontent.com/u/608762?v=4"},"body":"The printf utility provided by coreutils when interpreting '\\%o' format\ndoes not recognize %o as formatting directive. For example\nprintf '\\%o 0 returns \\%o and warning: ignoring excess arguments,\nstarting with ‘0’, which results in failed tests in\nt5309-pack-delta-cycles.sh. In most shells the test ends with success as\nthe printf is a builtin utility.\n\nFix it by using '\\\\%o' which is interpreted consistently in all versions\nof printf.\n\nSigned-off-by: Kacper Kornet <draenog@pld-linux.org>\n---\n\nI've found it while testing v1.8.5-rc0 with mksh which does not\nprovide a builtin printf.\n\nKacper\n\n t/lib-pack.sh | 8 ++++----\n 1 file changed, 4 insertions(+), 4 deletions(-)\n\ndiff --git a/t/lib-pack.sh b/t/lib-pack.sh\nindex 7e8685b..b96e125 100644\n--- a/t/lib-pack.sh\n+++ b/t/lib-pack.sh\n@@ -12,10 +12,10 @@\n # Print the big-endian 4-byte octal representation of $1\n uint32_octal () {\n \tn=$1\n-\tprintf '\\%o' $(($n / 16777216)); n=$((n % 16777216))\n-\tprintf '\\%o' $(($n /    65536)); n=$((n %    65536))\n-\tprintf '\\%o' $(($n /      256)); n=$((n %      256))\n-\tprintf '\\%o' $(($n           ));\n+\tprintf '\\\\%o' $(($n / 16777216)); n=$((n % 16777216))\n+\tprintf '\\\\%o' $(($n /    65536)); n=$((n %    65536))\n+\tprintf '\\\\%o' $(($n /      256)); n=$((n %      256))\n+\tprintf '\\\\%o' $(($n           ));\n }\n \n # Print the big-endian 4-byte binary representation of $1\n-- \n1.8.4.2\n\n-- \n  Kacper Kornet\n"},{"id":"229921","messageId":"20131031164920.GA18036@sigill.intra.peff.net","threadId":"35256","inReplyTo":"20131031115131.GA28379@camk.edu.pl","subject":"Re: [PATCH] Fix '\\%o' for printf from coreutils","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-10-31T16:49:21Z","receivedAt":"2013-10-31T16:49:21Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 31, 2013 at 12:51:32PM +0100, Kacper Kornet wrote:\n\n> The printf utility provided by coreutils when interpreting '\\%o' format\n> does not recognize %o as formatting directive. For example\n> printf '\\%o 0 returns \\%o and warning: ignoring excess arguments,\n> starting with ‘0’, which results in failed tests in\n> t5309-pack-delta-cycles.sh. In most shells the test ends with success as\n> the printf is a builtin utility.\n> \n> Fix it by using '\\\\%o' which is interpreted consistently in all versions\n> of printf.\n\nThanks, this makes sense. POSIX says:\n\n     [description of \\n, \\r, etc...]\n     The interpretation of a backslash followed by any other\n     sequence of characters is unspecified.\n\nso we were wrong to rely on an unknown backslash-escape\nbeing left alone. A quick grep seems indicate that this is\nthe only spot with the problem.\n\n-Peff\n"}]}