RE: qshell documentation, tutorial, rtm, rtfm and that genre

What Scott said. :)

But adding to that, there are instances when I have "sourced" .profile into
batch scripts that will be run via cron (the standard unix batch scheduler).


For example, you might want to run some Oracle process with all your
standard variables set, including ORACLE_HOME, et cetera. On a system where
different users utilize different versions of Oracle (and therefore
different ORACLE_HOME), one way to ensure that you get the right
environment, is to put in the top of your script:

. ~/.profile

I won't say there aren't other ways, but I have used this trick on many
occasions.

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"How is it that our memory is good enough to retain the least triviality
that happens to us, and yet not good enough to recollect how often we have
told it to the same person?"
-- Duc de La Rochefoucauld

The .profile script is only intended to be run during interactive
logins.

On a "real" Unix system, .profile is only run for a 'login shell',
meaning the user is signing into the Unix system. It's not run
otherwise.

Consider .profile as analogous to CHGUSRPRF USRPRF(you) INLPGM(foo).
When you set up an INLPGM for a user, it's only run once when the user
signs on. When that user submits a job, et al, it does not run the
INLPGM again for the submitted job. It's only run when the user starts
up interactively.

That's the behavior that .profile is supposed to have on a Unix
system... so IBM implemented it the same way in QShell. A submitted
job
doesn't run .profile, but an interactive login does.

Note certain other Unix shells (csh and tcsh, in particular) have two
separate startup scripts.... one that runs every time a new shell is
started, and one that's only run at initial login. However, the
bourne
shell derivatives (sh, ksh and bash) don't work that way.... they only
have .profile, and it's only run for interactive logins. And QShell
appears to be patterned after ksh (korn shell.)

Personally, I'm not crazy about the QShell default of only having
/usr/bin in the PATH. So I ran ADDENVVAR with LEVEL(*SYS) to change
the
default PATH so that it includes /usr/local/bin as well as some other
folders, and my PASE stuff. And because it's set at system-level,
it'll
automatically apply to all users, whether interactive or batch.


On 11/11/2010 12:37 AM, Don wrote:

Scott,

Perhaps you or Dennis could clarify something I hit about 10 years

ago...and

not used since...

When doing program calls that are SUBMITTED TASKS...the job

initiation

process in AIX/unix ignores the path statement in the .profile file

for the

profile that the task is running under. Last I recall, we had to

qualify

everything or change the path inside the script so that it pointed

where we

wanted it to...

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.