t6044 broken on pu

> The "seq" is not understood by all shells,
> using printf fixes this,
>
> index 20a3ffe..48d964e 100755
> --- a/t/t6044-merge-unrelated-index-changes.sh
> +++ b/t/t6044-merge-unrelated-index-changes.sh
> @@ -20,7 +20,7 @@ test_description="merges with unrelated index changes"
>  #   Commit E: renames a->subdir/a, adds subdir/e
>
>  test_expect_success 'setup trivial merges' '
> -       seq 1 10 >a &&
> +       printf 1 2 3 4 5 7 8 9 10 >a &&

> Torsten Bögershausen <tboegi@web.de> writes:
> 
>> The "seq" is not understood by all shells,
>> using printf fixes this,
>>
>> index 20a3ffe..48d964e 100755
>> --- a/t/t6044-merge-unrelated-index-changes.sh
>> +++ b/t/t6044-merge-unrelated-index-changes.sh
>> @@ -20,7 +20,7 @@ test_description="merges with unrelated index changes"
>>  #   Commit E: renames a->subdir/a, adds subdir/e
>>
>>  test_expect_success 'setup trivial merges' '
>> -       seq 1 10 >a &&
>> +       printf 1 2 3 4 5 7 8 9 10 >a &&
> 
> $ printf 1 2 3 4 5 7 8 9 10
> 1

> 
> 
> On 07/05/16 13:19, Andreas Schwab wrote:
>> Torsten Bögershausen <tboegi@web.de> writes:
>>
>>> The "seq" is not understood by all shells,
>>> using printf fixes this,
>>>
>>> index 20a3ffe..48d964e 100755
>>> --- a/t/t6044-merge-unrelated-index-changes.sh
>>> +++ b/t/t6044-merge-unrelated-index-changes.sh
>>> @@ -20,7 +20,7 @@ test_description="merges with unrelated index changes"
>>>  #   Commit E: renames a->subdir/a, adds subdir/e
>>>
>>>  test_expect_success 'setup trivial merges' '
>>> -       seq 1 10 >a &&
>>> +       printf 1 2 3 4 5 7 8 9 10 >a &&
>>
>> $ printf 1 2 3 4 5 7 8 9 10
>> 1
> 
> yep, I think:
> 
>     printf "%d\n" 1 2 3 4 5 6 7 8 9 10 >a &&
> 
> would be equivalent.
> 

> Torsten Bögershausen <tboegi@web.de> writes:
> 
>> The "seq" is not understood by all shells,
>> using printf fixes this,
>>
>> index 20a3ffe..48d964e 100755
>> --- a/t/t6044-merge-unrelated-index-changes.sh
>> +++ b/t/t6044-merge-unrelated-index-changes.sh
>> @@ -20,7 +20,7 @@ test_description="merges with unrelated index changes"
>>  #   Commit E: renames a->subdir/a, adds subdir/e
>>
>>  test_expect_success 'setup trivial merges' '
>> -       seq 1 10 >a &&
>> +       printf 1 2 3 4 5 7 8 9 10 >a &&
> 
> $ printf 1 2 3 4 5 7 8 9 10
> 1

> Torsten Bögershausen <tboegi@web.de> writes:
>
>> That's true, but the test passes anyway.
> You can also remove the body of the test and replace it with "true"
> and say "the test passes anyway".  Changing the test to use a file
> with only one line is irresponsible, if you do not know the nature
> of expected future bug that requires 10 lines to be there to
> manifest that the test wants to try.
>
> test_seq was invented exactly for the purpose of accomodating
> platforms that lack seq, so using it would probably be the best
> first step.  Updating implementation of test_seq to avoid $PERL
> would be a separate step, if desired (I personally do not think
> that is worth it).

> Torsten Bögershausen <tboegi@web.de> writes:
>
>> May a  simple
>>  printf "1\n2\n3\n4\n5\n6\n7\n8\n9\n10\n"
>>
>> be an option ?
> If you were to do that, at least have the decency to make it more
> readable by doing something like:
>
> 	printf "%s\n" 1 2 3 4 5 6 7 8 9 10
>
> ;-)
>
> But as I said, as a response to "t6044 broken on pu" bug report,
> s/seq/test_seq/ is the only sensible change.
>
> Improving "test_seq, the alternative to seq" is a separate topic.
>
> If you have aversion to $PERL, perhaps do them without using
> anything what is not expected to be built-in in modern shells,
> perhaps like this?

> On 08.05.16 20:20, Junio C Hamano wrote:
>> Torsten Bögershausen <tboegi@web.de> writes:
>>
>>> May a  simple
>>>  printf "1\n2\n3\n4\n5\n6\n7\n8\n9\n10\n"
>>>
>>> be an option ?
>> If you were to do that, at least have the decency to make it more
>> readable by doing something like:
>>
>> 	printf "%s\n" 1 2 3 4 5 6 7 8 9 10
>>
>> ;-)
>>
>> But as I said, as a response to "t6044 broken on pu" bug report,
>> s/seq/test_seq/ is the only sensible change.
>>
>> Improving "test_seq, the alternative to seq" is a separate topic.
>>
>> If you have aversion to $PERL, perhaps do them without using
>> anything what is not expected to be built-in in modern shells,
>> perhaps like this?
> Please don't get me wrong -

> Torsten Bögershausen <tboegi@web.de> writes:
>
>> May a  simple
>>  printf "1\n2\n3\n4\n5\n6\n7\n8\n9\n10\n"
>>
>> be an option ?
>
> If you were to do that, at least have the decency to make it more
> readable by doing something like:
>
>         printf "%s\n" 1 2 3 4 5 6 7 8 9 10
>
> ;-)
>
> But as I said, as a response to "t6044 broken on pu" bug report,
> s/seq/test_seq/ is the only sensible change.
>
> Improving "test_seq, the alternative to seq" is a separate topic.
>
> If you have aversion to $PERL, perhaps do them without using
> anything what is not expected to be built-in in modern shells,
> perhaps like this?
>
>  t/test-lib-functions.sh | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
> index 8d99eb3..4edddac 100644
> --- a/t/test-lib-functions.sh
> +++ b/t/test-lib-functions.sh
> @@ -739,7 +739,12 @@ test_seq () {
>         2)      ;;
>         *)      error "bug in the test script: not 1 or 2 parameters to test_seq" ;;
>         esac
> -       perl -le 'print for $ARGV[0]..$ARGV[1]' -- "$@"
> +       test_seq_counter__=$1
> +       while test "$test_seq_counter__" -le $2
> +       do
> +               echo "$test_seq_counter__"
> +               test_seq_counter__=$((test_seq_counter__ + 1))
> +       done
>  }

> > -       perl -le 'print for $ARGV[0]..$ARGV[1]' -- "$@"
> > +       test_seq_counter__=$1
> > +       while test "$test_seq_counter__" -le $2
> > +       do
> > +               echo "$test_seq_counter__"
> > +               test_seq_counter__=$((test_seq_counter__ + 1))
> > +       done
> >  }
> 
> Is that perl snippet ever called with non-numeric output?
> 
> perl -le 'print for $ARGV[0]..$ARGV[1]' -- A E
> A
> B
> C
> D
> E

> On Mon, May 09, 2016 at 08:30:51AM +0200, demerphq wrote:
>> > -       perl -le 'print for $ARGV[0]..$ARGV[1]' -- "$@"
>> > +       test_seq_counter__=$1
>> > +       while test "$test_seq_counter__" -le $2
>> > +       do
>> > +               echo "$test_seq_counter__"
>> > +               test_seq_counter__=$((test_seq_counter__ + 1))
>> > +       done
>> >  }
>>
>> Is that perl snippet ever called with non-numeric output?
>>
>> perl -le 'print for $ARGV[0]..$ARGV[1]' -- A E
>> A
>> B
>> C
>> D
>> E
>
> I had that thought, too, but I think it would be an error to do so.
> test_seq is supposed to be a replacement for "seq", which does not
> understand non-numeric sequences.

> > I had that thought, too, but I think it would be an error to do so.
> > test_seq is supposed to be a replacement for "seq", which does not
> > understand non-numeric sequences.
> 
> Although, the comment block just above test_seq() in
> test-lib-functions.sh says otherwise:
> 
>     Print a sequence of numbers or letters in increasing order.  This
>     is similar to GNU seq(1), but the latter might not be available
>     everywhere (and does not do letters).  It may be used like:
> 
>     for i in $(test_seq 100)
>     do
>         for j in $(test_seq 10 20)
>         do
>             for k in $(test_seq a z)
>             do
>                 echo $i-$j-$k
>             done
>         done
>     done

> On Mon, May 09, 2016 at 12:02:45PM -0400, Eric Sunshine wrote:
>
>> > I had that thought, too, but I think it would be an error to do so.
>> > test_seq is supposed to be a replacement for "seq", which does not
>> > understand non-numeric sequences.
>> 
>> Although, the comment block just above test_seq() in
>> test-lib-functions.sh says otherwise:
>> 
>>     Print a sequence of numbers or letters in increasing order.  This
>>     is similar to GNU seq(1), but the latter might not be available
>>     everywhere (and does not do letters).  It may be used like:
>> 
>>     for i in $(test_seq 100)
>>     do
>>         for j in $(test_seq 10 20)
>>         do
>>             for k in $(test_seq a z)
>>             do
>>                 echo $i-$j-$k
>>             done
>>         done
>>     done
>
> Oh, indeed. I apparently even Acked that documentation once upon a time. :-/
>
> Anyway, I double-checked my earlier "grep" and I do not think anybody is
> using that functionality. So I think we'd be OK to change it as long as
> we updated the documentation to match.

> Yes, I think the comment should just go.  Nobody used that alphabet
> form since it was written in d17cf5f3 (tests: Introduce test_seq,
> 2012-08-04).
>
>> I don't really care either way whether it is replaced or not (at one
>> point there were some people really interested in NO_PERL not even using
>> one-liners in the test suite, but I am not one of them).
>
> Neither am I, but I think it is prudent to drop that "letters".  The
> comment even says the letter form is not portable already, so the
> mention of GNU seq(1) is not helping at all.

> Subject: test-lib-functions.sh: remove misleading comment on test_seq
>
> We never used the "letters" form since we came up with "test_seq" to
> replace use of non-portable "seq" in our test script, which we
> introduced it at d17cf5f3 (tests: Introduce test_seq, 2012-08-04).
>
> We use this helper to either iterate for N times (i.e. the values on
> the lines do not even matter), or just to get N distinct strings
> (i.e. the values on the lines themselves do not really matter, but
> we care that they are different from each other and reproducible).
>
> Stop promising that we may allow using "letters"; this would open an
> easier reimplementation that does not rely on $PERL, if somebody
> later wants to.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
> @@ -718,20 +718,13 @@ test_cmp_rev () {
> -# Print a sequence of numbers or letters in increasing order.  This is
> -# similar to GNU seq(1), but the latter might not be available
> -# everywhere (and does not do letters).  It may be used like:
> -#
> -#      for i in $(test_seq 100)
> -#      do
> -#              for j in $(test_seq 10 20)
> -#              do
> -#                      for k in $(test_seq a z)
> -#                      do
> -#                              echo $i-$j-$k
> -#                      done
> -#              done
> -#      done
> +# Print a sequence of integers in increasing order, either with
> +# two arguments (start and end):
> +#
> +#     test_seq 1 5 -- outputs 1 2 3 4 5 one line at a time
> +#
> +# or with one argument (end), in which case it starts counting
> +# from 1.

> Stop promising that we may allow using "letters"; this would open an
> easier reimplementation that does not rely on $PERL, if somebody
> later wants to.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>

> Subject: [PATCH] test-lib-functions.sh: rewrite test_seq without Perl
>
> Rewrite the 'seq' imitation only with commands and features
> that are typically found as built-in in modern POSIX shells,
> instead of relying on Perl to run a single-liner.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
> @@ -679,7 +679,12 @@ test_seq () {
>         2)      ;;
>         *)      error "bug in the test script: not 1 or 2 parameters to test_seq" ;;
>         esac
> -       perl -le 'print for $ARGV[0]..$ARGV[1]' -- "$@"
> +       test_seq_counter__=$1
> +       while test "$test_seq_counter__" -le "$2"
> +       do
> +               echo "$test_seq_counter__"
> +               test_seq_counter__=$(( $test_seq_counter__ + 1 ))
> +       done
>  }

> Junio C Hamano <gitster@pobox.com> writes:
> 
> > Yes, I think the comment should just go.  Nobody used that alphabet
> > form since it was written in d17cf5f3 (tests: Introduce test_seq,
> > 2012-08-04).
> >
> >> I don't really care either way whether it is replaced or not (at one
> >> point there were some people really interested in NO_PERL not even using
> >> one-liners in the test suite, but I am not one of them).
> >
> > Neither am I, but I think it is prudent to drop that "letters".  The
> > comment even says the letter form is not portable already, so the
> > mention of GNU seq(1) is not helping at all.
> 
> -- >8 --
> Subject: test-lib-functions.sh: remove misleading comment on test_seq