×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
Hmmm. As usual I get a bit confused in the i(ntegrated) world we live
in on the System i. What threw me off, and lead me down the wrong path,
is that the variables I set using WRKENVVAR are all available when I
start Qshell, which led me to mistakenly believe that variable
substitution would work in Qshell using those variables I set before I
started Qshell. Well, since they ARE accessible to QShell it would be a
nice enhancement if they functioned similarly to the way other
Environment Variables do in Windows and Linux.
Here is the situation. I have an AIX based utility that works fine
within Qshell. The problem is, and this is common to many open source
projects, is that the projects continue to change versions frequently.
So I may have a situation where version 1.1 of MyCoolProject is named
MyCoolProject-1.1 and is extracted into folder /MyCoolProject-1.1 Well
about a week later I see that MyCoolProject version 1.2RC1 is
available. I download and extract it to folder /MyCoolProject-1.2RC1
Now I need to go into my Path and Classpath settings in a shell script
and change those references OR change the ALL the environment variables
that have the "old" folder reference in them OR rename folders
completely so they have the same name (like /MyCoolProject ) renaming
the original to something else and renaming the new folder to the
"generic" name. That makes it tough to test differences in versions.
In Windows (or Linux) I just change a single environment variable and
all the other variables that reference that variable immediately pick up
the change. "Switching" between versions is easy.
I could wrap the call the QSH and the launching of the utility in a CL
command and handle the setting of the variable there, I guess. I was
hoping for something simple and easy like setting one variable and
running QSH.
Thanks, again, for setting me straight. I'll need to think on this a bit.
Pete
Scott Klement wrote:
Hi Pete,
Seeing your instructions below (thanks!) I realize that I should have
clarified that I want to set the variables using the WRKENVVAR command.
WRKENVVAR?? That's a whole different subject altogether, Pete! Your
last message stated that you were using QSH (in the subject line) and
WRKENVVAR is not part of QSH, and that's what threw me off.
Anyway... the ability to use $VAR inside another variable is purely a
Unix-shell thing. You can do it from within QShell, since QShell
emulates a Unix-shell. But, WRKENVVAR is a CL command. (as are
ADDENVVAR and CHGENVVAR which is more likely what you really mean) In
CL, you can't insert an environment variable by preceding it with a
dollar-sign... that's just not part of CL's syntax.
CL is not a good language for working with environment variables -- at
present, it doesn't even have a means of retrieving the value of an
environment variable without calling an API.
Here's an example of how you might do this in RPG, however:
H DFTACTGRP(*NO)
D getenv PR * extproc('getenv')
D varname * value options(*string)
D putenv PR 10i 0 extproc('putenv')
D varval * value options(*string)
D MY_HOME s 1024A varying
D CLASSPATH s 1024A varying
D val s *
/free
val = getenv('MY_HOME');
if (val = *NULL);
my_home = '';
else;
my_home = %str(val);
endif;
val = getenv('CLASSPATH');
if (val = *NULL);
classpath = '';
else;
classpath = %str(val);
endif;
classpath += ':' + my_home;
putenv('CLASSPATH=' + classpath);
return;
/end-free
As you can see... it's waaaay easier to do in QShell. (Though, the RPG
code will certainly run faster!) Consider setting your variable in
QShell if possible.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.