RE: Exporting variables in QShell

Blair,

That was awesome!  Thank you so much.

Kristen

> -----Original Message-----
> From: java400-l-bounces@xxxxxxxxxxxx 
> [mailto:java400-l-bounces@xxxxxxxxxxxx] On Behalf Of Blair Wyman
> Sent: Monday, September 19, 2005 6: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
> 
> 
> 
> -- 
> This is the Java Programming on and around the iSeries / 
> AS400 (JAVA400-L) mailing list To post a message email: 
> JAVA400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change 
> list options,
> visit: http://lists.midrange.com/mailman/listinfo/java400-l
> or email: JAVA400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/java400-l.
> 
> 
>