[DaGuy]

Until you get a load of this one:

Say I have a bash script named DBENV that basically sets some environment variables. What is the difference between executing

> . DBENV

or

> ./DBENV


note: in the first command, there is a space between the period and the script name.

I ask, because I'm messing (learning) with Oracle9i and the first one works fine while the second causes problems i.e. SQLPLUS cannot find a dynamic library.

Thanks!

[howardm4]

the first one basically says to
'source' the script in the current
shell.

The second one says 'create a new child shell
and execute the script in that and oh,
by the way, the script is located in
the curent directory', and return to
thhe current shell when the child is done.

Doesn't suprise me at all
that the 2nd one doesn't work quite
right

[absmiths]

You're right, that WAS dumb!

[DaGuy]

You were dying to use that icon, weren't you.




Howardm4's answer the mechanics of the commands. Thanks very much for that.

Alas, It's a bit confusing since I don't see why executing in the current shell versus the forked one produces different results. The forked one would have the same commands.

Is it the case, that the child process has additional (or different) runtime constraints not faced by the parent one i.e., permissions etc.

I'm not one bit clear on how variable scope is being handled or for that matter when to use
". scriptname" versus "./scriptname". I have always executed scripts with as "./scriptname" and never had hit an obstacle -until this point. Then again, I wasn't playing with major league app like Oracle9i.

Any help appreciated.

Thanks!

[howardm4]

what happens is that bash calls the
'execve' system call in the
current shell and the new child
shell is intialized w/ the environment
as stated by environ(7) (ie. do a
man environ).

If you have some oddball dynamic library
and the DYLD_LIBRARY_PATH variable set
in the current shell (do a 'env'),
it won't get passed to the child.

[diamondsw]

Well *I* learned something here so I'm happy.

However, don't kid yourself - there are stupid questions, as anyone who works in the business world knows.

[DaGuy]

Thanks, I see what's going on.



But what's the motivation for not passing identical enviroment vars to the child process?

Naively speaking, it seems safer to execute shells scripts as ". scriptname" then "./scriptname" since you risk loosing environment information in the former.

Wadda you think?

Thanks again for the discussion -hope it continues.

[howardm4]

how does your current environment find
this special dynamic library? what do you
set?

[DaGuy]

Below are contents of the actual script. It doesn't appear to contain anything out of the ordinary.

What's giving me the headache is understanding the motivation, which then would justify when to use ". scriptname" as opposed to "./scriptname".

---------------------------------------


# Required for the database application.
export CLASSPATH=$S/DBCreate/oradev/classes/orapts.jar:$CLASSPATH
# Required for JDBC connection
export CLASSPATH=$S/jdbc/lib/classes12.zip:$CLASSPATH


echo ORACLE_SID: $ORACLE_SID
echo ORACLE_HOME: $ORACLE_HOME
echo SRCHOME: $SRCHOME
echo PATH: $PATH
echo DYLD_LIBRARY_PATH: $DYLD_LIBRARY_PATH
echo CLASSPATH: $CLASSPATH

echo Done Setting parameters


---------------------------------------

In case it helps:

DYLD_LIBRARY_PATH=/Users/oracle/9iR2/orahome/lib:/Users/oracle/9iR2/orahome/rdbms/

Thanks!

[howardm4]

So all you want to do is use this
script file to set a few variables
and prevent you from having to type
all that junk over and over so that
you be in a shell, then run this
script (which you want to modify
the shell you're in) and then do
whatever?

Unix doesn't work like that.

Parent processes fork (create)
children processes. The children
do their work and then quit and
control is returned to the parent.

The child CANNOT affect the parent
in that way. That is the entire
reason for the '. script' syntax.
That syntax says 'pretend that I just
typed this stuff in, here and now'.

The other way (./script) does teh
whole child creation thing. So even
if the child inherited everything from
the parent, it wouldn't change zippo
in your case.

Of course, you could put that stuff in
your .profile or whatever so that all
shells read it upon startup.

[DaGuy]

I see... This makes me look at things a bit differently going forward. UNIX always keeps me on my toes.

Thanks, for clarifying matters. I appreciate it.