Re: [PATCH] tests: turn on test-lint-shell-syntax by default
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jan 27, 2013, 17:34 UTC
- Message-ID
- <7v4ni2y1fm.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <5105280A.80002@web.de>
Torsten Bögershausen <tboegi@web.de> writes:
> Back to the which: > ... > and running "make test" gives the following, at least in my system: > ...
I think everybody involved in this discussion already knows that; the point is that it can easily give false negative, without the scripts working very hard to do so.
If we did not care about incurring runtime performance cost, we could arrange:
- the test framework to define a variable $TEST_ABORT that has a full path to a file that is in somewhere test authors cannot touch unless they really try hard to (i.e. preferrably outside $TRASH_DIRECTORY, as it is not uncommon for to tests to do "rm *" there). This location should be per $(basename "$0" .sh) to allow running multiple tests in paralell;
- the test framework to "rm -f $TEST_ABORT" at the beginning of test_expect_success/failure;
- test_expect_success/failure to check $TEST_ABORT and if it exists, abort the execution, showing the contents of the file as an error message.
Then you can wrap commands whose use we want to limit, perhaps like this, in the test framework:
which () {
cat >"$TEST_ABORT" <<-\EOF
Do not use unportable 'which' in the test script.
"if type $cmd" is a good way to see if $cmd exists.
EOF
} sed () {
saw_wantarg= must_abort=
for arg
do
if test -n "$saw_wantarg"
then
saw_wantarg=
continue
fi
case "$arg" in
--) break ;; # end of options
-i) echo >"$TEST_ABORT" "Do not use 'sed -i'"
must_abort=yes
break ;;
-e) saw_wantarg=yes ;; # skip next arg
-*) continue ;; # options without arg
*) break ;; # filename
esac
done
if test -z "$must_abort"
sed "$@"
fi
}Then you can check that TEST_ABORT does not appear in test scripts (ensuring that they do not attempt to circumvent the mechanis) and catch use of unwanted commands or unwanted extended features of commands at runtime.
But this will incur runtime performace hit, so I am not sure it would be worth it.