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

Commit Message

H.Merijn Brand Dec. 1, 2018, 5:07 p.m. UTC

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 <[e-mail]>
Tested-by: H.Merijn Brand - Tux <[e-mail]>

Comments

Jeff King Dec. 1, 2018, 7:38 p.m. UTC | #1

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

> 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

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

> This patch was tested with PATH=$PATH, PATH=.:$PATH, PATH=$PATH:.,
> PATH=$PATH:.:/bin, PATH=:$PATH, PATH=$PATH:, and PATH=$PATH::/bin
> [...]
> +test_lazy_prereq DOT_IN_PATH '
> +       case ":$PATH:" in
> +       *:.:*|*::*) true  ;;
> +       *)          false ;;
> +       esac
> +'

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

Junio C Hamano Dec. 3, 2018, 12:29 a.m. UTC | #2

Jeff King <[e-mail]> writes:

> 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:
> ...

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).

Junio C Hamano Dec. 3, 2018, 1 a.m. UTC | #3

"H.Merijn Brand" <[e-mail]> writes:

> 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

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

> Subject: [PATCH] t0061: do not fail test if '.' is part of $PATH

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.

> +test_lazy_prereq DOT_IN_PATH '
> +       case ":$PATH:" in
> +       *:.:*|*::*) true  ;;
> +       *)          false ;;
> +       esac
> +'
> +
> +test_expect_success !DOT_IN_PATH 'run_command is restricted to PATH' '
>         write_script should-not-run <<-\EOF &&
>         echo yikes
>         EOF

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(-)

diff --git a/t/t0061-run-command.sh b/t/t0061-run-command.sh
index cf932c8514..17b560370e 100755
--- a/t/t0061-run-command.sh
+++ b/t/t0061-run-command.sh
@@ -29,7 +29,15 @@ test_expect_success 'run_command can run a command' '
 	test_must_be_empty err
 '
 
-test_expect_success 'run_command is restricted to PATH' '
+
+test_lazy_prereq RUNS_COMMANDS_FROM_PWD '
+	write_script runs-commands-from-pwd <<-\EOF &&
+	true
+	EOF
+	runs-commands-from-pwd >/dev/null 2>&1
+'
+
+test_expect_success !RUNS_COMMANDS_FROM_PWD 'run_command is restricted to PATH' '
 	write_script should-not-run <<-\EOF &&
 	echo yikes
 	EOF

Patch

diff --git a/t/t0061-run-command.sh b/t/t0061-run-command.sh
index cf932c851..557f87442 100755
--- a/t/t0061-run-command.sh
+++ b/t/t0061-run-command.sh
@@ -29,7 +29,14 @@  test_expect_success 'run_command can run a command' '
        test_must_be_empty err
 '

-test_expect_success 'run_command is restricted to PATH' '
+test_lazy_prereq DOT_IN_PATH '
+       case ":$PATH:" in
+       *:.:*|*::*) true  ;;
+       *)          false ;;
+       esac
+'
+
+test_expect_success !DOT_IN_PATH 'run_command is restricted to PATH' '
        write_script should-not-run <<-\EOF &&
        echo yikes
        EOF