Eric Blake wrote:
According to Paolo Bonzini on 1/28/2008 11:10 PM:
|
|> I inadvertently stripped the leading
|> ./, so atlocal wasn't being sourced if the current directory was not in
|> the path in absolute form.
|
| I didn't know source used the path. Actually I thought the contrary...
. has always used PATH; but in older shells, it also implicitly tacked .
onto its path search. Since this was a security hole for trojan files,
POSIX forbids implicit `.'. Thus, the only safe way to source a file in
the current directory is with anchored notation, since you can't rely on
`.' being in the user's PATH.
Uhm, I have:
bonzinip$ echo echo foo > bar
bonzinip$ . bar
foo
And . is not in the PATH:
bonzinip$ chmod +x bar
bonzinip$ bar
-bash: bar: command not found
Then I try within scripts and behavior is the same:
bonzinip$ echo . bar > baz
bonzinip$ chmod +x baz
bonzinip$ sh --version
GNU bash, version 2.05b.0(1)-release (powerpc-apple-darwin8.0)
bonzinip$ ./baz
foo
bonzinip$ POSIXLY_CORRECT=1 sh baz
foo
Even with bash 3.2:
bonzinip$ /sw/bin/bash --version
GNU bash, version 3.2.9(1)-release (powerpc-apple-darwin8.10.0)
Copyright (C) 2005 Free Software Foundation, Inc.
bonzinip$ /sw/bin/bash baz
foo
bonzinip$ POSIXLY_CORRECT=1 /sw/bin/bash baz
foo
/me is confused...
Paolo
