Re: [PATCH] t9100: fix breakage when SHELL_PATH is not /bin/sh

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 8, 2016, 20:12 UTC
Message-ID: <xmqqd1s77yhg.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <alpine.DEB.2.20.1602082056410.2964@virtualbox>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> write_script is a semantically unambiguous way to specify what we *want*.
> And it would allow us to handle chmod specifically for Windows *in one
> place only*.

Correct. write_script, for the intended target of the helper, is a way to write a script that can later be invoked by the test with the name "$1". It is conceivable for write_script on UNIX to be writing into "$1" while Windows version to be writing into "$1.bat" and the script, i.e. the user of the write_script helper, to do this

	write_script foo <<EOF &&
        ...
        EOF
	...
        foo

which may result in foo.bat running on Windows without us having to adjust the test script. So it indeed is a very nice abstraction to have.

But the way the test uses this exec.sh script is not consistent with that. exec.sh for this test is merely a data, whose content must exactly match what later tests expect, i.e. it wants it to begin with "#!/bin/sh" and its execute bit on, even though the test does not have no intention to run it as a script.

So I think it was doubly wrong for me to suggest write_script without realizing that this is _not_ writing a script in the usual sense for us to write with write_script.