Argl,... you're right,... ;) Now I looked up all definitions in the standard,.... but didn't use a non-interactive shell. With a non-interactive shell, dash behaves correctly: $ cat test.sh echo 1 . foo echo 2
bash$ sh test.sh 1 .: 2: foo: not found bash$ # exited btw: bash even exits in the interactive-shell case,... should we report this? On Sun, 2010-07-04 at 18:58 -0500, Raphael Geissert wrote: > HOWEVER, there's something interesting: > $ dash > $ PS1='dash$ ' > dash$ . foo > .: 2: foo: not found > dash$ . /dev/foo > .: 3: Can't open /dev/foo > $ > > It exits even if it is an interactive shell. The only difference between the > two is that '. foo' means "look for 'foo' in $PATH and execute its commands," > while '. /dev/foo' means "execute /dev/foo's commands." Did you really use /dev/foo (which didn't exist I suppose)? Or did you rather use /dev/null or so? > That IMO would be the bug. > > (FTR, bash and others consider the former form as a combination of the two > forms, i.e. they look for the argument in $PATH and if not found they look > for > it in ./) > > The problem I see with that interpretation of POSIX, is that there's no way > for a script to know if 'dot' failed because the file argument was not > readable, even with set -e. > > Btw, those links point to POSIX:2008, but Debian Policy requires SUSv3 > (a.k.a. > POSIX:2004.) Cheers, Chris. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
