t4151 missing quotes

> skipping through some failed tests I found more (smaller) problems
> inside the test... when test arguments are empty they need to be
> quoted (quite a lot test in this sentence).
>
> Error is like
> t4151-am-abort.sh[5]: test: argument expected
>
> My patch:
>
> *** t4151-am-abort.sh   Mon May  9 17:51:44 2016
> --- t4151-am-abort.sh.orig      Fri Apr 29 23:37:00 2016
> ***************
> *** 67,73 ****
>   test_expect_success 'am -3 --skip removes otherfile-4' '
>         git reset --hard initial &&
>         test_must_fail git am -3 0003-*.patch &&
> !       test 3 -eq "$(git ls-files -u | wc -l)" &&
>         test 4 = "$(cat otherfile-4)" &&
>         git am --skip &&
>         test_cmp_rev initial HEAD &&
> --- 67,73 ----
>   test_expect_success 'am -3 --skip removes otherfile-4' '
>         git reset --hard initial &&
>         test_must_fail git am -3 0003-*.patch &&
> !       test 3 -eq $(git ls-files -u | wc -l) &&
>         test 4 = "$(cat otherfile-4)" &&
>         git am --skip &&
>         test_cmp_rev initial HEAD &&
> ***************

> On Mon, May 9, 2016 at 12:09 PM, Armin Kunaschik
> <megabreit@googlemail.com> wrote:
>> *** t4151-am-abort.sh   Mon May  9 17:51:44 2016
>> --- t4151-am-abort.sh.orig      Fri Apr 29 23:37:00 2016
>> !       test 3 -eq "$(git ls-files -u | wc -l)" &&
>> !       test 3 -eq $(git ls-files -u | wc -l) &&
>
> Some comments:
>
> Quoting the output of 'wc -l' will break the tests on Mac OS X and BSD
> since the output contains leading whitespace which won't match the "3"
> on the other side of the '='.

> Your diff is backward, comparing 'current' against 'original', which
> makes it difficult to read. Reviewers on this list expect to see
> 'original' compared against 'current'.
>
> Use a unified format to make the diff easier to read; or just use
> git-diff or git-format patch, which is even simpler.
>
> It's not clear how the output of 'wc -l' could ever be the empty
> string. Perhaps git-ls-files is dying and causing the pipe to abort
> before 'wc -l' ever outputs anything? Without additional information
> about the problem you're experiencing, it's difficult to judge if this
> change is a good idea.

> On Mon, May 9, 2016 at 12:09 PM, Armin Kunaschik
> <megabreit@googlemail.com> wrote:
>> skipping through some failed tests I found more (smaller) problems
>> inside the test... when test arguments are empty they need to be
>> quoted (quite a lot test in this sentence).
>>
>> Error is like
>> t4151-am-abort.sh[5]: test: argument expected
>>
>> My patch:
>>
>> *** t4151-am-abort.sh   Mon May  9 17:51:44 2016
>> --- t4151-am-abort.sh.orig      Fri Apr 29 23:37:00 2016
>> ***************
>> *** 67,73 ****
>>   test_expect_success 'am -3 --skip removes otherfile-4' '
>>         git reset --hard initial &&
>>         test_must_fail git am -3 0003-*.patch &&
>> !       test 3 -eq "$(git ls-files -u | wc -l)" &&
>>         test 4 = "$(cat otherfile-4)" &&
>>         git am --skip &&
>>         test_cmp_rev initial HEAD &&
>> --- 67,73 ----
>>   test_expect_success 'am -3 --skip removes otherfile-4' '
>>         git reset --hard initial &&
>>         test_must_fail git am -3 0003-*.patch &&
>> !       test 3 -eq $(git ls-files -u | wc -l) &&
>>         test 4 = "$(cat otherfile-4)" &&
>>         git am --skip &&
>>         test_cmp_rev initial HEAD &&
>> ***************
>
> Some comments:
>
> Quoting the output of 'wc -l' will break the tests on Mac OS X and BSD
> since the output contains leading whitespace which won't match the "3"
> on the other side of the '='.
>
> Your diff is backward, comparing 'current' against 'original', which
> makes it difficult to read. Reviewers on this list expect to see
> 'original' compared against 'current'.
>
> Use a unified format to make the diff easier to read; or just use
> git-diff or git-format patch, which is even simpler.
>
> It's not clear how the output of 'wc -l' could ever be the empty
> string. Perhaps git-ls-files is dying and causing the pipe to abort
> before 'wc -l' ever outputs anything? Without additional information
> about the problem you're experiencing, it's difficult to judge if this
> change is a good idea.

> *** ./t4151-am-abort.sh.orig    Fri Apr 29 23:37:00 2016
> --- ./t4151-am-abort.sh Mon May  9 18:28:18 2016
> ***************
> *** 82,88 ****
>         test 4 = "$(cat otherfile-4)" &&
>         git am --abort &&
>         test_cmp_rev initial HEAD &&
> !       test -z $(git ls-files -u) &&
>         test_path_is_missing otherfile-4
>   '
>
> --- 82,88 ----
>         test 4 = "$(cat otherfile-4)" &&
>         git am --abort &&
>         test_cmp_rev initial HEAD &&
> !       test -z "$(git ls-files -u)" &&
>         test_path_is_missing otherfile-4
>   '

>
> Thanks for a report and an analysis of the issue.
>
> -- >8 --
> From: Armin Kunaschik <megabreit@googlemail.com>
> Subject: t4151: make sure argument to 'test -z' is given
>
> 88d50724 (am --skip: revert changes introduced by failed 3way merge,
> 2015-06-06), unlike all the other patches in the series, forgot to
> quote the output from "$(git ls-files -u)" when using it as the
> argument to "test -z", leading to a syntax error.
>
> Note that $(git ls-files -u | wc -l) are deliberately left unquoted,
> as some implementations of "wc -l" includes extra blank characters
> in its output and cannot be compared as string, i.e. "test 0 = $(...)".
>
> Signed-off-by:
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>  t/t4151-am-abort.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/t/t4151-am-abort.sh b/t/t4151-am-abort.sh
> index 833e7b2..b878c21 100755
> --- a/t/t4151-am-abort.sh
> +++ b/t/t4151-am-abort.sh
> @@ -82,7 +82,7 @@ test_expect_success 'am -3 --abort removes otherfile-4' '
>         test 4 = "$(cat otherfile-4)" &&
>         git am --abort &&
>         test_cmp_rev initial HEAD &&
> -       test -z $(git ls-files -u) &&
> +       test -z "$(git ls-files -u)" &&
>         test_path_is_missing otherfile-4
>  '
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

> Something like this follows Documentation/SubmittingPatches [...]
>
> -- >8 --
> From: Armin Kunaschik <megabreit@googlemail.com>
> Subject: t4151: make sure argument to 'test -z' is given
>
> 88d50724 (am --skip: revert changes introduced by failed 3way merge,
> 2015-06-06), unlike all the other patches in the series, forgot to
> quote the output from "$(git ls-files -u)" when using it as the
> argument to "test -z", leading to a syntax error.

> Signed-off-by:
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>  t/t4151-am-abort.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/t/t4151-am-abort.sh b/t/t4151-am-abort.sh
> index 833e7b2..b878c21 100755
> --- a/t/t4151-am-abort.sh
> +++ b/t/t4151-am-abort.sh
> @@ -82,7 +82,7 @@ test_expect_success 'am -3 --abort removes otherfile-4' '
>         test 4 = "$(cat otherfile-4)" &&
>         git am --abort &&
>         test_cmp_rev initial HEAD &&
> -       test -z $(git ls-files -u) &&
> +       test -z "$(git ls-files -u)" &&
>         test_path_is_missing otherfile-4
>  '

> On Mon, May 9, 2016 at 2:56 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Something like this follows Documentation/SubmittingPatches [...]
>>
>> -- >8 --
>> From: Armin Kunaschik <megabreit@googlemail.com>
>> Subject: t4151: make sure argument to 'test -z' is given
>>
>> 88d50724 (am --skip: revert changes introduced by failed 3way merge,
>> 2015-06-06), unlike all the other patches in the series, forgot to
>> quote the output from "$(git ls-files -u)" when using it as the
>> argument to "test -z", leading to a syntax error.
>
> To make it clear that this was not a syntax error in the typical case,
> it might make sense to say:
>
>     ...potentially leading to a syntax error if some earlier tests failed.

> Eric Sunshine <sunshine@sunshineco.com> writes:
>> On Mon, May 9, 2016 at 2:56 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Something like this follows Documentation/SubmittingPatches [...]
>>>
>>> -- >8 --
>>> From: Armin Kunaschik <megabreit@googlemail.com>
>>> Subject: t4151: make sure argument to 'test -z' is given
>>>
>>> 88d50724 (am --skip: revert changes introduced by failed 3way merge,
>>> 2015-06-06), unlike all the other patches in the series, forgot to
>>> quote the output from "$(git ls-files -u)" when using it as the
>>> argument to "test -z", leading to a syntax error.
>>
>> To make it clear that this was not a syntax error in the typical case,
>> it might make sense to say:
>>
>>     ...potentially leading to a syntax error if some earlier tests failed.
>
> Hmph, do we have a broken &&-chain?

> If an earlier test fails and leaves an unmerged path, "ls-files -u"
> would give some output, so "test -z" would get one or more non-empty
> strings; if we feed multiple, this would fail.  But we would not have
> even run "test -z" as long as we properly &&-chain these tests.
>
> I think the real issue is when the earlier step succeeds and does
> not leave any unmerged path.  In that case, we would run "test -z"
> without anything else on the command line, which would lead to an
> syntax error.
>
>     Side Note: /usr/bin/test and test (built into bash and dash)
>     seem not to care about the lack of string in "test -z <string>"
>     and "test -n <string>".  It appears to me that they just take
>     "-z" and "-n" without "<string>" as a special case of "test
>     <string>" that is fed "-z" or "-n" as <string>.  Apparently, the
>     platform Armin is working on doesn't.

> Perhaps
>
>     ... leading to a syntax error on some platforms whose "test"
>     does not interpret "test -z" (no other arguments) as testing if
>     a string "-z" is the null string (which GNU test and test that
>     is built into bash and dash seem to do).
>
> would be an improvement?

>>
>> Hmph, do we have a broken &&-chain?
>
> I don't know. Unfortunately, Armin didn't provide much information in
> his initial email, saying only "skipping through some failed tests",
> which doesn't necessarily indicate if those tests failed or if he
> somehow manually skipped them.

>> If an earlier test fails and leaves an unmerged path, "ls-files -u"
>> would give some output, so "test -z" would get one or more non-empty
>> strings; if we feed multiple, this would fail.  But we would not have
>> even run "test -z" as long as we properly &&-chain these tests.
>>
>> I think the real issue is when the earlier step succeeds and does
>> not leave any unmerged path.  In that case, we would run "test -z"
>> without anything else on the command line, which would lead to an
>> syntax error.

>>     Side Note: /usr/bin/test and test (built into bash and dash)
>>     seem not to care about the lack of string in "test -z <string>"
>>     and "test -n <string>".  It appears to me that they just take
>>     "-z" and "-n" without "<string>" as a special case of "test
>>     <string>" that is fed "-z" or "-n" as <string>.  Apparently, the
>>     platform Armin is working on doesn't.
>
> I also tested on Mac OS X and BSD, and they happily accept bare "test
> -n", as well (though, I don't doubt that there are old shells which
> complain).