Configuration Information [Automatically generated, do not change]:
Machine: i486
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2 -Wall
uname output: Linux sc.homeunix.net 2.6.25-rc8 #1 PREEMPT Fri Apr 4 08:56:07
BST 2008 i686 GNU/Linux
Machine Type: i486-pc-linux-gnu
Bash Version: 3.2
Patch Level: 39
Release Status: release
Description:
I don't know if that's a known issue, but it seems to break
POSIX and be inconsistent with the documentation.
$ POSIXLY_CORRECT=1 sh --norc
sh-3.2$ cat > a
echo foo
sh-3.2$ type a
sh: type: a: not found
sh-3.2$ . a
foo
sh-3.2$ help .
.: . filename [arguments]
Read and execute commands from FILENAME and return. The pathnames
in $PATH are used to find the directory containing FILENAME. If any
ARGUMENTS are supplied, they become the positional parameters when
FILENAME is executed.
sh-3.2$ echo "$PATH"
/usr/local/bin:/usr/bin:/bin:/usr/games:/usr/sbin:/sbin:/usr/local/sbin
According to POSIX, "." shouldn't look for "a" in the current
directory because "." and "" (and of course any path to the
current directory) are not in my $PATH.
$ ash -c '. a'
.: 1: a: not found
$ posh -c '. a'
posh: .: a: not found
$ ksh -c '. a'
ksh[1]: .: a: cannot open [No such file or directory]
$ pdksh -c '. a'
pdksh: .: a: not found
$ zsh -c '. a'
zsh:.:1: no such file or directory: a
SUSv3> If file does not contain a slash, the shell shall use the
SUSv3> search path specified by PATH to find the directory
SUSv3> containing file. Unlike normal command search, however, the
SUSv3> file searched for by the dot utility need not be
SUSv3> executable. If no readable file is found, a non-interactive
SUSv3> shell shall abort; an interactive shell shall write a
SUSv3> diagnostic message to standard error, but this condition
SUSv3> shall not be considered a syntax error.
[...]
SUSv3> Some older implementations searched the current directory
SUSv3> for the file, even if the value of PATH disallowed it. This
SUSv3> behavior was omitted from this volume of IEEE Std
SUSv3> 1003.1-2001 due to concerns about introducing the
SUSv3> susceptibility to trojan horses that the user might be
SUSv3> trying to avoid by leaving dot out of PATH .
Cheers,
Stephane
