patcht7610 test for mktemp existence

Subject: t7610: test for mktemp before test execution

mktemp is not available on all platforms, so the test 'temporary filenames are used with mergetool.writeToTemp' fails there. This patch does not replace mktemp but just disables the test that otherwise would fail. mergetool checks itself before executing mktemp and reports an error.

Signed-off-by: Armin Kunaschik <megabreit@googlemail.com>

---

Armin Kunaschik <megabreit@googlemail.com> writes:

Thanks.

This makes me wonder what would happen to the leftover directory, though. Would it be a better idea to clean it up as well, i.e.

	tempdir=$(mktemp -d -t foo.XXXXXX) &&
	test -d "$tempdir" &&
        rmdir "$tempdir"

On Wed, Jul 06, 2016 at 11:23:51AM -0700, Junio C Hamano wrote:

Lazy prereq's are computed inside a temporary directory[1] that is automatically cleaned up, so I think the code here does not have to worry about it.

-Peff

[1] Coincidentally, I recently wanted to have a lazy prereq check
    _another_ prereq inside it. But it turns out you cannot do this:

      test_lazy_prereq RECURSE_INNER '
        echo inner >file
      '
      test_lazy_prereq RECURSE_OUTER '
        echo outer >file &&
	test_have_prereq RECURSE_INNER &&
	echo outer >expect &&
	test_cmp expeect file
      '
      test_expect_success 'lazy prereqs can recurse' '
	test_have_prereq RECURSE_OUTER
      '

    because they both use the same temporary directory (so beyond having
    "outer" see "inner" in the file, it actually complains when the
    inner check removes the directory entirely).

    The fix for that is simple: give the tempdir a unique name. But I
    think this kind of recursion is still not OK in the shell because
    without the "local" keyword, we have no concept of stack variables,
    and so stomp on the globals with each iteration.

    Anyway. Not a big deal, and I ended up simplifying my tests not to
    need it. But I was certainly surprised and confused by it at the
    time, so I figured it was worth sharing the knowledge. :)

Junio C Hamano <gitster@pobox.com> writes:

It turns out that this is not necessary since day one of lazy_prereq. I forgot what I wrote in 04083f27 (test: allow prerequisite to be evaluated lazily, 2012-07-26).

Thanks.