[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "make check" failure [with "." at beginning of PATH]
From: |
Jim Meyering |
Subject: |
Re: "make check" failure [with "." at beginning of PATH] |
Date: |
Sun, 10 Feb 2008 11:35:18 +0100 |
Bruno Haible <address@hidden> wrote:
> Jim Meyering wrote:
>> ... this is the first such failure report I've seen for 6.10.
>
> Of course, I checked the mailing list archive before submitting the report.
>
>> > There are two problems:
>> > 1) Backquotes should be used instead of bash-specific syntax.
>>
>> Since November, tests and infrastructure can use POSIX-shell syntax
>> like $() on most systems. See the posix-shell gnulib module and
>> this change by Paul Eggert:
>>
>> http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=1379ed974
>
> It was luck that my /bin/sh understands the $(...) syntax. The macro in
Calling it "luck" implies that there is a significant chance something
will go wrong. These days, if posix-shell.m4 can't find a usable shell,
then you're using a broken system or a museum piece.
> m4/posix-shell.m4 has two possible outcomes: either it finds a POSIX shell,
> or it doesn't. In the latter case, PREFERABLY_POSIX_SHELL will be /bin/sh
> and will *not* necessarily support $(...) syntax. But you wrote $(dirname ...)
> unconditionally.
IMHO, that's perfectly fine.
I have yet to hear of any system on which that approach fails.
>> > 2) 'dirname' refers to the program in PATH. My $PATH starts with ".". "."
>> > is
>>
>> Ah ha! *That* is the problem.
>> Don't put "." in your PATH at all, and especially not at the front.
>
> PATH is a personal preference. Many people set it like I do. Don't expect
> that PATH is set like you prefer it.
I'd argue that few people put "." anywhere in PATH, since
doing so constitutes a well-known security risk.
I'm surprised that you would put "." before directories like /usr/bin.
>> If you see an easy, clean fix, then great.
>
> I see two easy, clean fixes:
> - Rename the unit test file 'dirname' to 'test-dirname' or 'dirname-test'
> or 'dirname.sh' or something like this.
> - Use
> sed -e 's,^[^/]*$,.,' -e 's,//*[^/]*$,,'
> instead of dirname.
Thanks. I like the latter, so I've accommodated like this:
Avoid test failure when run with risky PATH ("." before /usr/bin).
* build-aux/check.mk (approx_dirname_filter): Define.
(am__check_pre): Emulate dirname using sed.
Report and suggested fix from Bruno Haible in
http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/12587/focus=12590
diff --git a/build-aux/check.mk b/build-aux/check.mk
index 34169f5..f35007b 100644
--- a/build-aux/check.mk
+++ b/build-aux/check.mk
@@ -89,6 +89,11 @@ tput sgr0 >/dev/null 2>&1 && \
# by disabling -e (using the XSI extension "set +e") if it's set.
SH_E_WORKAROUND = case $$- in *e*) set +e;; esac
+# Emulate dirname with sed.
+# This approximation fails when the input is a single-component
+# absolute directory name like /foo, but that never happens here.
+approx_dirname_filter = sed 's,^[^/]*$$,.,;s,//*[^/]*$$,,'
+
# To be inserted before the command running the test. Creates the
# directory for the log if needed. Stores in $dir the directory
# containing $src, and passes TESTS_ENVIRONMENT.
@@ -96,7 +101,7 @@ am__check_pre = \
$(SH_E_WORKAROUND); \
tst=`echo "$$src" | sed 's|^.*/||'`; \
rm -f address@hidden; \
-$(mkdir_p) "$$(dirname $@)" || exit; \
+$(mkdir_p) "$$(echo '$@'|$(approx_dirname_filter))" || exit; \
if test -f "./$$src"; then dir=./; \
elif test -f "$$src"; then dir=; \
else dir="$(srcdir)/"; fi; \
--
1.5.4.35.g3cfc