RE: Exporting variables in QShell

Blair,
Thanks for the full & complete answer.

Terry

-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx
[mailto:java400-l-bounces@xxxxxxxxxxxx] On Behalf Of Blair Wyman
Sent: Monday, September 19, 2005 5:29 AM
To: Java Programming on and around the iSeries / AS400
Subject: Re: Exporting variables in QShell

java400-l-bounces@xxxxxxxxxxxx wrote on 09/16/2005 11:50:45 AM:

> In conjunction with trying Hibernate and Spring, we have some very
long
> classpaths.
> We have tried to set up QShell scripts that we can run to set the
> classpath for different situations.

I've got good news and bad news:

Bad news: It will never work to run a "script" to set environment
variables, since a called shell script can never change its caller's
environment.

Good news: What does work is called "sourcing" a file, where the
shell effectively runs each line of the file as if it were
entered by hand in the current shell.

To source a file in QShell, use the dot.  If you have a file
'setVars' containing your export commands you could do:
   . setVars
..at the command prompt to set those variables in the current shell.

Here's a shell session that might help -- I added the line numbers
for clarity's sake.

        1 > set | grep FOOBAR
        2   $
        3 > cat setVars
        4   export FOOBAR=BAZ
        5   $
        6 > setVars
        7   $
        8 > set | grep FOOBAR
        9   $
       10 > . setVars
       11   $
       12 > set | grep FOOBAR
       13   FOOBAR=BAZ
       14   $

   Line 1 calls the 'set' command, which dumps all current
   variables, and the grep looks for the one I want to set: FOOBAR.
   The lack of any output in line 2 shows that FOOBAR is not set.

   I built a little file called 'setVars' that contains one line
   (line 4).

   On line 6 I try running setVars as a script, and then
   check again -- line 9 shows the export didn't work.

   On line 10 I source the setVars file, and check again -- now
   the variable is set (line 13) and we're off to the races.

Now the importance of using 'export' becomes pertinent when you
talk about calling 'child' scripts.  When you just say
      FOO=BAR
you set a local variable that is not passed to child shells.
By adding the 'export' command you ensure the child shells
can see the variable.

Here's another little shell session:

        1 > cat setVars
        2   export FOOBAR=BAZ
        3   BAZ=BONK
        4   $
        5 > . setVars
        6   $
        7 > set | grep BAZ
        8   BAZ=BONK
        9   FOOBAR=BAZ
       10   $
       11 > qsh
       12   $
       13 > set | grep BAZ
       14   FOOBAR=BAZ
       15   $

   I added (line 3) to setVars to set a local
   variable called BAZ.  After sourcing setVars, both
   variables are set (lines 8 and 9).  However,
   when I start a new shell on line 11 and check
   again, only FOOBAR is set, showing that BAZ=BONK was
   local to the first shell.

> A script may consist of a single line like:
> export -s CLASSPATH='.:/java/lib/jt400.jar:java/lib/utility.jar'

Just try 'dotting' (sourcing) these files -- I think you'll be pleased.

> If we enter the export command directly in QShell it works.  If we run
> it in a script it does not work.
> It acts like all variables are local to the script and can not be
> exported.

Exactly correct.  It's a sort of fundamental tenet of UNIX
shell scripting that you cannot change your _caller's_ environment:
only your own and those of your own children.

HTH.

-blair


  ___   _           Blair Wyman                  IBM Rochester
 ( /_)  /  _  ' _   (507)253-2891            blairw@xxxxxxxxxx
__/__)_/_<_/_/_/_'  Opinions expressed may not be those of IBM