Re: Shell source with relative pathname does not work

[Bill Maas <bill@xxxxxxxx>]

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

--
To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html