# t0090-cache-tree fails due to wc whitespace 8 messages from 2011-12-14 to 2011-12-20. Participants: Brian Gernhardt, Stefano Lattarini, Hallvard Breien Furuseth, Johannes Sixt, Thomas Rast, Andreas Schwab. Thread: https://gitlist.dev/t/29164 ## Brian Gernhardt, 2011-12-14 14:35 Subject: t0090-cache-tree fails due to wc whitespace Message-ID: <7F1792D2-8ED4-4546-8ED4-52B95E0AE9FC@silverinsanity.com> URL: https://gitlist.dev/e/7F1792D2-8ED4-4546-8ED4-52B95E0AE9FC%40silverinsanity.com ``` It's time for my periodic complaint: People assuming `wc -l` outputs just a number. wc on OS X (and perhaps other BSD-like systems) always aligns the output in columns, even with the -l flag. Generally this results in a quick patch from me to remove some unneeded quotes. However, this time it's used in a more complex manner: echo "SHA " \ "($(git ls-files|wc -l) entries, 0 subtrees)" >expect && cmp_cache_tree expect This results in errors like: --- expect 2011-12-14 14:26:26.000000000 +0000 +++ filtered 2011-12-14 14:26:26.000000000 +0000 @@ -1 +1 @@ -SHA ( 1 entries, 0 subtrees) +SHA (1 entries, 0 subtrees) I was able to fix this by adding a sed command to remove leading spaces: - "($(git ls-files|wc -l) entries, 0 subtrees)" >expect && + "($(git ls-files|wc -l|sed -e 's/^ *//') entries, 0 subtrees)" >expect && But I'm not sure if this is the best way to solve the issue. ~~ Brian Gernhardt ``` ## Stefano Lattarini, 2011-12-14 14:57 Subject: Re: t0090-cache-tree fails due to wc whitespace Message-ID: <201112141557.26794.stefano.lattarini@gmail.com> URL: https://gitlist.dev/e/201112141557.26794.stefano.lattarini%40gmail.com In-Reply-To: <7F1792D2-8ED4-4546-8ED4-52B95E0AE9FC@silverinsanity.com> ``` On Wednesday 14 December 2011, Brian Gernhardt wrote: > It's time for my periodic complaint: People assuming `wc -l` > outputs just a number. wc on OS X (and perhaps other BSD-like > systems) always aligns the output in columns, even with the -l > flag. > It surely does so on Solaris 10 as well: $ echo x | wc -l 1 $ for i in {1..1000}; do echo x; done | wc -l 1000 Regards, Stefano ``` ## Hallvard Breien Furuseth, 2011-12-14 15:09 Subject: Re: t0090-cache-tree fails due to wc whitespace Message-ID: URL: https://gitlist.dev/e/hbf.20111214ogjn%40bombur.uio.no In-Reply-To: <7F1792D2-8ED4-4546-8ED4-52B95E0AE9FC@silverinsanity.com> ``` Brian Gernhardt writes: > I was able to fix this by adding a sed command to remove leading spaces: > > - "($(git ls-files|wc -l) entries, 0 subtrees)" >expect && > + "($(git ls-files|wc -l|sed -e 's/^ *//') entries, 0 subtrees)" >expect && > > But I'm not sure if this is the best way to solve the issue. Well, tr -d ' ' saves all of 7 characters from sed -e 's/^ *//'. -- Hallvard ``` ## Johannes Sixt, 2011-12-14 15:41 Subject: Re: t0090-cache-tree fails due to wc whitespace Message-ID: <4EE8C3AD.9050605@viscovery.net> URL: https://gitlist.dev/e/4EE8C3AD.9050605%40viscovery.net In-Reply-To: <7F1792D2-8ED4-4546-8ED4-52B95E0AE9FC@silverinsanity.com> ``` Am 12/14/2011 15:35, schrieb Brian Gernhardt: > It's time for my periodic complaint: People assuming `wc -l` outputs > just a number. wc on OS X (and perhaps other BSD-like systems) always > aligns the output in columns, even with the -l flag. Generally this > results in a quick patch from me to remove some unneeded quotes. > However, this time it's used in a more complex manner: > > echo "SHA " \ > "($(git ls-files|wc -l) entries, 0 subtrees)" >expect && > cmp_cache_tree expect I'd solve it by moving the command substitution outside the quoted string: printf "SHA (%d entries, 0 subtrees)\n" \ $(git ls-files | wc -l) >expect && Other proposed solutions add another process. I don't like that on Windows ;) -- Hannes ``` ## Thomas Rast, 2011-12-14 15:43 Subject: Re: t0090-cache-tree fails due to wc whitespace Message-ID: <201112141643.06656.trast@student.ethz.ch> URL: https://gitlist.dev/e/201112141643.06656.trast%40student.ethz.ch In-Reply-To: <7F1792D2-8ED4-4546-8ED4-52B95E0AE9FC@silverinsanity.com> ``` Brian Gernhardt wrote: > > It's time for my periodic complaint: People assuming `wc -l` outputs > just a number. wc on OS X (and perhaps other BSD-like systems) > always aligns the output in columns, even with the -l flag. Oops. > Generally this results in a quick patch from me to remove some > unneeded quotes. However, this time it's used in a more complex > manner: [...] > - "($(git ls-files|wc -l) entries, 0 subtrees)" >expect && > + "($(git ls-files|wc -l|sed -e 's/^ *//') entries, 0 subtrees)" >expect && I'm tempted to say we should define test_wc_l () { test $# = 0 || error "bug in test script: passing arguments to wc -l is not portable" wc -l | tr -d -c 0-9 } just to avoid issues if any wc comes across and prints a tab for padding or says "hi, the number of lines you wanted to know is: 42". (Oddly, according to 'man 1p wc' here, the POSIXly correct format in the absence of options is "%d %d %d %s\n", , , , Taking it literally would mean no padding/alignment whatsoever. Neither GNU wc on my Linux exactly conforms to this.) -- Thomas Rast trast@{inf,student}.ethz.ch ``` ## Andreas Schwab, 2011-12-14 15:54 Subject: Re: t0090-cache-tree fails due to wc whitespace Message-ID: URL: https://gitlist.dev/e/m2ehw7jgis.fsf%40igel.home In-Reply-To: <201112141643.06656.trast@student.ethz.ch> ``` Thomas Rast writes: > (Oddly, according to 'man 1p wc' here, the POSIXly correct format in > the absence of options is > > "%d %d %d %s\n", , , , > > Taking it literally would mean no padding/alignment whatsoever. > Neither GNU wc on my Linux exactly conforms to this.) A space in the format string stands for one or more s. If only a single is allowed the standard uses 𝚫. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ``` ## Johannes Sixt, 2011-12-20 08:24 Subject: [PATCH] t0090: be prepared that 'wc -l' writes leading blanks Message-ID: <4EF04635.6020406@viscovery.net> URL: https://gitlist.dev/e/4EF04635.6020406%40viscovery.net In-Reply-To: <4EE8C3AD.9050605@viscovery.net> ``` From: Johannes Sixt Use 'printf %d $(whatever|wc -l)' so that the shell removes the blanks for us. Signed-off-by: Johannes Sixt --- Am 12/14/2011 16:41, schrieb Johannes Sixt: > I'd solve it by moving the command substitution outside the quoted string: > > printf "SHA (%d entries, 0 subtrees)\n" \ > $(git ls-files | wc -l) >expect && > > Other proposed solutions add another process. I don't like that on Windows ;) And here is a proper patch to that effect. -- Hannes t/t0090-cache-tree.sh | 6 ++---- 1 files changed, 2 insertions(+), 4 deletions(-) diff --git a/t/t0090-cache-tree.sh b/t/t0090-cache-tree.sh index f972562..6c33e28 100755 --- a/t/t0090-cache-tree.sh +++ b/t/t0090-cache-tree.sh @@ -17,15 +17,13 @@ cmp_cache_tree () { # test-dump-cache-tree already verifies that all existing data is # correct. test_shallow_cache_tree () { - echo "SHA " \ - "($(git ls-files|wc -l) entries, 0 subtrees)" >expect && + printf "SHA (%d entries, 0 subtrees)\n" $(git ls-files|wc -l) >expect && cmp_cache_tree expect } test_invalid_cache_tree () { echo "invalid (0 subtrees)" >expect && - echo "SHA #(ref) " \ - "($(git ls-files|wc -l) entries, 0 subtrees)" >>expect && + printf "SHA #(ref) (%d entries, 0 subtrees)\n" $(git ls-files|wc -l) >>expect && cmp_cache_tree expect } -- 1.7.8.1499.g39f909 ``` ## Thomas Rast, 2011-12-20 09:17 Subject: Re: [PATCH] t0090: be prepared that 'wc -l' writes leading blanks Message-ID: <87d3bjlhze.fsf@thomas.inf.ethz.ch> URL: https://gitlist.dev/e/87d3bjlhze.fsf%40thomas.inf.ethz.ch In-Reply-To: <4EF04635.6020406@viscovery.net> ``` Sorry for slacking off on replying to this thread... Johannes Sixt writes: > Use 'printf %d $(whatever|wc -l)' so that the shell removes the blanks > for us. > > Signed-off-by: Johannes Sixt > --- > Am 12/14/2011 16:41, schrieb Johannes Sixt: >> I'd solve it by moving the command substitution outside the quoted string: >> >> printf "SHA (%d entries, 0 subtrees)\n" \ >> $(git ls-files | wc -l) >expect && >> >> Other proposed solutions add another process. I don't like that on Windows ;) > > And here is a proper patch to that effect. Acked-by: Thomas Rast This is the best solution also because it the formatting more (instead of less) readable. -- Thomas Rast trast@{inf,student}.ethz.ch ```