|
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. > > >
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.