Shell source with relative pathname does not work

Shell source with relative pathname does not work

[Bill Maas]

Hi folks,

since I couldn't figure out how to join the Dash mailing list I'm
posting this message directly to dash@vger.kernel.org , and I just hope
it will arrive properly.

First my compliments for the excellent work you are doing: I used to
believe that slowness was just another shell feature.

I possibly found a bug in Dash:

. x.conf
.: 1: x.conf: not found

The source fails, even though x.conf is definitely there. The following
variants do succeed:

. /path/to/x.conf
. ./x.conf

Well, that's all. Clear enough I guess. Keep up the good work.

Bill

Re: Shell source with relative pathname does not work

[Oleg Verych]

Bill Maas @ Sun, 27 Apr 2008 09:53:57 +0200:
* Organization: STSX DOT ORG

> Hi folks,
[]
> First my compliments for the excellent work you are doing: I used to
> believe that slowness was just another shell feature.

Hallo, Bill. Please see history of the Almquist shell; you will find
interesting info there: http://www.in-ulm.de/~mascheck/various/ash/

As for optimization, IMHO `dash` is in deep bug-fixing mode. However
NetBSD version has some development wrt speed:

http://cvsweb.netbsd.org/bsdweb.cgi/src/bin/sh/var.c?rev=1.35&content-type=text/x-cvsweb-markup

> I possibly found a bug in Dash:
>
> . x.conf
> .: 1: x.conf: not found
>
> The source fails, even though x.conf is definitely there. The following
> variants do succeed:
>
> . /path/to/x.conf
> . ./x.conf

http://www.opengroup.org/onlinepubs/009695399/utilities/dot.html

So, behavior must be as for ordinary binaries -- searching PATH and
not current dir. by default. IMHO quite good decision -- care where
you are, and what you are executing.

`bash` seem to do searching in `.', but this must be its feature.
-- 
sed 'sed && sh + olecom = love' << ''
-o--=O`C
 #oo'L O
<___=E M

executing with Bash (Re: Shell source with relative pathname does not work)

[Oleg Verych]

> `bash` seem to do searching in `.', but this must be its feature.

And this one seem like potential problem:

Bash actually finds valid "commands" (other than first line with
'%PDF-1.3') in a PDF file and tries to execute them.

olecom@flower:/tmp$ dash -c '. ./AT32UC3A-doc32058.pdf'
: not founddoc32058.pdf: 1: %PDF-1.2
./AT32UC3A-doc32058.pdf: 1: Syntax error: Unterminated quoted string
olecom@flower:/tmp$ bash -c '. ./AT32UC3A-doc32058.pdf'
./AT32UC3A-doc32058.pdf: line 1: fg: no job control
./AT32UC3A-doc32058.pdf: line 2: 57950: command not found
olecom@flower:/tmp$
olecom@flower:/tmp$ dash -c '. ./foo.pdf'
: not found1: %PDF-1.3
./foo.pdf: 1: Syntax error: Unterminated quoted string
olecom@flower:/tmp$ bash -c '. ./foo.pdf'
./foo.pdf: line 1: fg: no job control
./foo.pdf: line 2: e: command not found
./foo.pdf: line 2: g: command not found
./foo.pdf: line 2: 102: command not found
olecom@flower:/tmp$


Even '-e' flag is somewhat wired:


olecom@flower:/tmp$ dash -e -c '. ./foo.pdf'
: not found1: %PDF-1.3
olecom@flower:/tmp$
olecom@flower:/tmp$ bash -e -c '. ./foo.pdf'
./foo.pdf: line 1: fg: no job control
olecom@flower:/tmp$
____

Re: Shell source with relative pathname does not work

[Bill Maas]

Hello Oleg,

thanks for your reply.

On Sun, 2008-04-27 at 13:54 +0200, Oleg Verych wrote:

> http://www.opengroup.org/onlinepubs/009695399/utilities/dot.html
> 
> So, behavior must be as for ordinary binaries -- searching PATH and
> not current dir. by default. IMHO quite good decision -- care where
> you are, and what you are executing.

. file           fails
. path/to/file   succeeds (note the missing leading /)

> `bash` seem to do searching in `.', but this must be its feature.

So in the second case, dash must be doing the same as bash. I think that
from the point of security, failing in the first case and not in the
second is a bit odd. The safe criterium should be "starts with a slash
or a dot" (not: contains a slash).

But since the sourcing program has either already been checked for exec
bit and leading [./] or presence in PATH or has been started as "sh
file", any limitation is probably overdone. And whether performed from a
script or from the commandline, it's just another case of "[builtin]
command arg".

The PATH thing applies to executables which are to be run with no
executing command (such as "sh"), hence the search path is limited.
Sourced files do not run on their own (so to speak), so PATH does not
apply here. Sourcing scripts should be trusted to know what they want,
no need to think for them.

IMHO;) Hope I'm being a bit clear.

Thanks,

Bill

Re: Shell source with relative pathname does not work

[Bill Maas]

Hi Oleg,

I'm very sorry, but I obviously missed a crucial point here: the shell
_searches_ the PATH for an executable file to be sourced. I'm still not
convinced about the need for (and security of) such a feature, however..

But it's a design choice, and I'll respect it. Just have to take care to
prepend relative pathnames from the commandline/config with a "./" in my
scripts.

I don't expect to be bothering you again with this one;)

Bill

Re: Shell source with relative pathname does not work

[H. Peter Anvin]

Bill Maas wrote:
> 
> I'm very sorry, but I obviously missed a crucial point here: the shell
> _searches_ the PATH for an executable file to be sourced. I'm still not
> convinced about the need for (and security of) such a feature, however..
> 

POSIX.1:2004:

If file does not contain a slash, the shell shall use the search path 
specified by PATH to find the directory containing file. Unlike normal 
command search, however, the file searched for by the dot utility need 
not be executable. If no readable file is found, a non-interactive shell 
shall abort; an interactive shell shall write a diagnostic message to 
standard error, but this condition shall not be considered a syntax error.

	-hpa