Re: t6044 broken on pu

From: Torsten Bögershausen <tboegi@web.de>
Date: May 9, 2016, 04:43 UTC
Message-ID: <6871653f-248f-ef9a-1947-0ed88783ad8b@web.de>
In-Reply-To: <xmqqoa8gza1t.fsf@gitster.mtv.corp.google.com>

On 08.05.16 20:20, Junio C Hamano wrote:

Show 21 quoted lines

> 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 - I wasn't really clear why: I think that the invocation of an external program to produce a 10 line test program is a waste of CPU cycles - in this very use case.

We can try to use the ideal tool to do the job, in this case the fork() that needs to be done to invoke perl seems rather expensive in relation to what we get in terms of functionality - a file with 10 lines of content.

I recently read a message why "grep | sed" is not ideal, when sed can do everything that grep needs to do, and only 1 external program needs to be invoked - not 2.

I try to apply the same pattern to this TC: Stay in the shell, as long as possible. But if you really need perl for e.g. regexp, then use it.