". filename" can't find file when run from /bin/sh, works from /bin/bash; why?

Issue

My simple script is like this:

#!/bin/sh


DEF=.file_name_with_a_leading_dot.sh

. ${DEF}

Notice the /bin/sh on the top line.
When I run that simple script I get an error that the file isn’t found.
But, if I change that top line to #!/bin/bash then the script finds that file in the current directory just fine.

But, On my Ubuntu linux laptop I see that /bin/sh is a symlink to /bin/bash . So, why does my script behave differently?

Also, I can run the script like this:

/bin/bash ./script.sh

And it’s OK.

So, what am I missing?

Solution

From the Manpage:

. filename [arguments]

source filename [arguments] Read and execute
commands from filename in the current shell environment and return the
exit status of the last command executed from filename. If filename
does not contain a slash, file names in PATH are used to find the
directory containing filename.
The file searched for in PATH need not
be executable. When bash is not in posix mode, the current directory
is searched if no file is found in PATH.
If the sourcepath option to
the shopt builtin command is turned off, the PATH is not searched. If
any arguments are supplied, they become the positional parameters when
filename is executed. Otherwise the positional parameters are
unchanged. The return status is the status of the last command exited
within the script (0 if no commands are executed), and false if
filename is not found or cannot be read.

So, it seems that the shebang #!/bin/sh sets your bash to posix mode. In this mode, only PATH is evaluated, not the current directory.

Answered By – Manuel Barbe

This Answer collected from stackoverflow, is licensed under cc by-sa 2.5 , cc by-sa 3.0 and cc by-sa 4.0

Leave a Reply

(*) Required, Your email will not be published