[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: autoconf 2.49c fails if '.' is in PATH
From: |
Akim Demaille |
Subject: |
Re: autoconf 2.49c fails if '.' is in PATH |
Date: |
19 Feb 2001 17:45:46 +0100 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) |
Alexandre Oliva <address@hidden> writes:
> On Feb 3, 2001, Akim Demaille <address@hidden> wrote:
>
> > The question is `is $FILE an executable in the common sense'.
>
> I think the best thing to do is to just ignore the issue of whether
> the found executable is a directory while testing -x or -f, and test
> for -d later on, notifying the user and possibly aborting. This
> second test might have false positives on Cygwin if x/ and x.exe
> exist, but I really don't care. I'd rather warn the user that
> something bad is about to happen.
>
> As a data point to support this choice, directories aren't generally
> skipped when searching the PATH. So why should we?
What do you mean?
/tmp % mkdir executable nostromo 17:43
/tmp % PATH=/tmp which executable nostromo 17:43
executable not found
/tmp % which -a which nostromo Err 1
which: shell built-in command
/usr/bin/which
/tmp % PATH=/tmp /usr/bin/which executable nostromo 17:44
/tmp/executable
Arg... Is this really good? Are there any other PATH walking
programs behaving like this?
RE: autoconf 2.49c fails if '.' is in PATH, Tim Van Holder, 2001/02/04
Re: autoconf 2.49c fails if '.' is in PATH, Akim Demaille, 2001/02/02
RE: autoconf 2.49c fails if '.' is in PATH, Bernard Dautrevaux, 2001/02/02