Thread (1 message) 1 message, 1 author, 2016-06-16

Re: t6044 broken on pu

From: Junio C Hamano <hidden>
Date: 2016-06-16 02:19:16

Torsten Bögershausen [off-list ref] writes:
On 08.05.16 20:20, Junio C Hamano wrote:
quoted
Torsten Bögershausen [off-list ref] writes:
quoted
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 -
I don't.
I wasn't really clear why:
So is it now clear?

The title of the bug report is "t6044 broken on pu". The analysis of
the issue is "We use 'test_seq 1 10' when we want one to ten on each
line in the output to use in test to make sure it is portable, but a
new commit forgot the portability issue and used seq instead".

The only sensible fix is "Use test_seq like everybody else".

Improving the implementation of test_seq is a totally separate
issue.  It may be a good thing to do independently to save external
program, and the effect of such change will not be limited to t6044
but all other existing users of test_seq.

And that is why it must be done as a separate topic.

Why you think it is a good idea to update t6044 with printf
"1\n2\n3\n4\n5\n6\n7\n8\n9\n10\n" is beyond me--don't you want to
make sure that existing users of test_seq benefits the same way?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help