bash script export path

casperdaghost · 05-25-2012, 06:38 AM

I see this as the first line after the shebang in the bashscripts at work

I really don't understatnd what is does -

Code:

export PATH="`dirname "$0"`:$PATH"; . _env.sh

My scripts seem to work just fine without it .

acid_kewpie · 05-25-2012, 06:40 AM

it will add the directory that the script is in to its path, whatever it is. Yuck. better off without it.

casperdaghost · 05-25-2012, 07:17 AM

I kinda thought that it opens up an new shell for iteration of the loop.

What use is there in exporting the path

acid_kewpie · 05-25-2012, 07:19 AM

loop? what loop?

casperdaghost · 05-25-2012, 09:49 AM

Yeah - forget the loop.
I though maybe that this would open up the program in an independend shell, and each loop gets send to antoher shell.
that is not it though.

What does the . mean in bash.
In perl it means a concatination - and I though that is what is was doing here - concatatining this directory to executable path.
but it is not.
And when I look up period bash in google I get nothing

What is the period in bash mean (it is not a regular epressions either)

David the H. · 05-25-2012, 10:46 AM

In this case "." is the source command. There is no need to do anything special for concatenation in the shell. Just stick things together. The PATH setting command you asked about is doing just that.

See here for a fairly-complete list of all specially-treated characters in bash:

http://www.tldp.org/LDP/abs/html/special-chars.html

catkin · 05-25-2012, 10:55 AM

Looks like there is/was an optional _env.sh script in each directory with shellscript files. If _env.sh exists it would work like a shell "library", from the name probably used to configure the shell/scripting environment and/or set environment variables.

BTW the ";" at the end of export PATH="`dirname "$0"`:$PATH"; terminates the first command so the whole line is functionally equivalent to (and more obscure than):

Code:

export PATH="`dirname "$0"`:$PATH"
. _env.sh

acid_kewpie · 05-25-2012, 12:55 PM

Hmm, but a source doesn't use $PATH. "_env.sh" will always be in the current directory. I'd be more given to think it was to maybe override system programs? a copy of ls in the current directory woul be used in preference to /bin/ls

ntubski · 05-25-2012, 11:18 PM

Quote:

Originally Posted by acid_kewpie

Hmm, but a source doesn't use $PATH. "_env.sh" will always be in the current directory.

Nope, source does use path:

Code:

~$ help .
.: . filename [arguments]
    Execute commands from a file in the current shell.
    
    Read and execute commands from FILENAME in the current shell.  The
    entries in $PATH are used to find the directory containing FILENAME.
    If any ARGUMENTS are supplied, they become the positional parameters
    when FILENAME is executed.
    
    Exit Status:
    Returns the status of the last command executed in FILENAME; fails if
    FILENAME cannot be read.

Nominal Animal · 05-26-2012, 12:10 AM

For what its worth, I've used

Code:

#!/bin/sh
BASE="`dirname "$0"`"

[ -r "$BASE/filename.sh" ] && . "$BASE/filename.sh"

to source another script from the same directory as the original script when writing widely compatible Bourne shell/POSIX shell scripts that cannot rely on being installed in a specific directory. Note that if you do not need to be compatible with ancient versions of /bin/sh, it is better to use BASE="$(dirname "$0")"

Note that sourcing another file means the other file is essentially "included", executed using the same shell instance. In particular, all variables and functions set by the other file will be available to the original script too. This is often used for setting configuration values, so that they only need to be updated in one file only. For an example, look at your service scripts in /etc/init.d/. (Note however that they source their files using fixed paths.)

Although you often see the test flag using -e (exists) or -x (is executable), the -r (is readable) is more appropriate. You do not need execute rights to source a file, only read rights.