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

Hi Don,

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...