patchDo not fail test if '.' is part of $PATH

When $PATH contains the current directory as .:PATH, PATH:., PATH:.:PATH, or (maybe worse) as :PATH, PATH:, or PATH::PATH - as an empty entry is identical to having dot in $PATH - this test used to fail

This patch was tested with PATH=$PATH, PATH=.:$PATH, PATH=$PATH:., PATH=$PATH:.:/bin, PATH=:$PATH, PATH=$PATH:, and PATH=$PATH::/bin

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Tested-by: H.Merijn Brand - Tux <h.m.brand@xs4all.nl>

On Sat, Dec 01, 2018 at 06:07:57PM +0100, H.Merijn Brand wrote:

Good catch. The test cares about Git not accidentally adding "." to the PATH, but we can't check that if it is already there.

Since the test is ultimately checking "can we run should-not-run from the current directory", might it be simpler to actually try that as the precondition? I.e., something like:

  test_expect_success 'create program in current directory' '
	write_script should-not-run <<-\EOF &&
	echo yikes
	EOF
  '

  test_lazy_prereq DOT_IN_PATH '
	should-not-run
  '

  test_expect_success !DOT_IN_PATH 'run_command is restricted to PATH' '
	test_must_fail test-tool run-command run-command should-not-run
  '

?

That's more lines, but we don't have to peek into the details of how $PATH works.

-Peff

Jeff King <peff@peff.net> writes:

A nice egg of columbus. It also would save us from mischievous users who have should-not-run somewhere no the $PATH that outputs the string we expect (no, I do not think it is a common thing to do; I am just saying that the solution covers such an extremely stupid case without special casing).

"H.Merijn Brand" <h.m.brand@xs4all.nl> writes:

It is totally unclear what "this test" refers to. Let's retitle it to

and do something like this:

    t0061 created a script named with an unlikely name in the
    current directory to ensure that it is not found via the
    run_command() API, expecting that $PATH does not contain an
    element that names the current directory (i.e. '.' or '') in a
    sane environment.  This obviously would not work if the $PATH
    does contain such an element.

    Introduce a DOT_IN_PATH lazy prerequisite to catch such a case
    and skip the test when the environment is not so sane.

I also like Peff's more straight-forward approach that avoids looking into PATH but instead ask the shell what we care about (i.e. would we end up running 'should-not-run' if we asked the system to run it without giving an explicit path to it?). The last paragraph of the above would need to change if we were to go in that direction to something like

    Check if the running shell picks up the script without an
    explicit path to it and skip the test when it does.

perhaps. The code to do so got a bit more compact than what Peff wrote but I think it still retains its main beauty, which is how straight-forward it is.

 t/t0061-run-command.sh | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)