RE: Changing an existing PATH as seen in QSHELL

It is a release of an application that has no *set* time schedule.
Sometimes it can be a few months (weeks if patching) and sometimes over
a year. So I need to install the new code, change the path to include
it
and then do some testing. Being able to quickly change the path is the
important part. So I think I have ended up with the best overall
solution.

I see. Makes sense. But before you put this to bed, and in keeping with
the "don't over-modify .profile" concept, here is what we would usually do
on a Unix system for that sort of application-specific issue:

Create a file in /usr/local/etc, say called "inzMyApp.sh"

(You may have to create /usr/local/etc, but that's a customization standard
that I highly recommend.)

In that file, put the initialization parameters for the application:
MYVAR1="SomeValue": export MYVAR1
MYVAR2="SomeOtherValue": export MYVAR2
PATH=${MYVAR1}:${MYVAR2}:PATH; export PATH
et cetera

Modify your .profile again, this time pulling out the application-specific
stuff and replacing with:

. /usr/local/etc/inzMyApp.sh

(Yes, that period and space are there on purpose. It causes a "source"
operation. Effectively, the inzMyApp.sh script is read as though it was
part of .profile. (You can look up "source kornshell" or "source unix
shell" on google if you're curious)

From now on, your maintenance will be in the application directory, not in

your home directory.

Where this really pays off (besides keeping your .profile relatively clean)
is when more than one person needs the same initialization parameters. Now,
one maintenance one place will have effect on everyone involved. Then
there's the versioning opportunity that's solved by this approach, but
that's a discussion for a later time.

Regards,

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"It's a recession when your neighbor loses his job; it's a depression when
you lose your own."
-- Harry S. Truman