Am confused - The all important . (period) - ????

[newbie_01]

Hi,

My apologies if this question is so trivial ... I guess there really is a room for dummies ...

Anyway, just wanting to know if someone can please explain what the dot (.) infront of the command or script does and why it works and does not work in the following?

server01(oracle)[]/u01/bin/oracle/server01$: db01env
ksh: db01env: cannot execute
server01(oracle)[]/u01/bin/oracle/server01$: . db01env
Set up for db01 database (using: /opt/oracle/9.2.0.7)
oracle:db01> ls -l /u02/bin/oracle/db01env
-rw-r--r--   1 root     other       1621 Jun 26  2005 /u02/bin/oracle/db01env

I did a which db01env and it says it is not found even though /u02/bin/oracle is included in the PATH environment variable. I believe this is because db01env is not executable and the which command only checks for executables, is that a correct assumption/guess?

Am not having issues at the moment but just curious how a single dot could make such a big difference that it can make or break stuff

Any response or explanation is very much appreciated.

Thanks in advance.

[sgosnell]

The period means 'current directory' or 'here'. You have to tell bash where to do things for some commands. Two periods, '..', means the directory above the current one. For instance, 'cd ..' means change to the directory one level higher than the current one.

[Cabhan]

Although sgosnell is correct that '.' means "the current directory" when used in a path, this is a different use.

Here, '.' is an alias for the command "source". What "source" does is to execute the given file IN THE CURRENT SHELL. This is different from running a command normally, which executes in a subshell and cannot affect the current shell. Sourcing a script is usually used to define environment variables, aliases, etc. Sourcing is the operation performed on your bashrc file in order to cause its definitions to apply to the current shell.

If the named file does not exist in the current directory (as in your case), $PATH is searched for a file with that name, which is why it works for you.

So why does simply executing the script not work? Because the script does not have execute permissions. Run this command to make it executable:

chmod +x /u02/bin/oracle/db01env

In general, you should execute scripts normally unless you are explicitly in need of sourcing it. This protects the shell from unintended or malicious side effects of scripts.

[tetsujin]

In general, you should execute scripts normally unless you are explicitly in need of sourcing it. This protects the shell from unintended or malicious side effects of scripts.

It protects you, I guess, from scripts loading environment variables, function definitions, aliases, and shell extensions that you don't want... But if it's malicious code, those things are probably the least of your worries.