Torsten Bögershausen <tboegi@xxxxxx> writes: > On 08.05.16 20:20, Junio C Hamano wrote: >> Torsten Bögershausen <tboegi@xxxxxx> 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 - 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? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html