Ooo ... ouch.   The pain of profiling.
And unlike CMS,  there is no global address space
where these things can be put.

I STRONGLY recommend that you not set variables in  $HOME/.bashrc
for two reasons.   First,  it is specific to only that one shell.
But secondly,  and perhaps more important,  it is  "instance sourced".
That is,  .bashrc  is sourced for EVERY instance of BASH.
Good for aliasing and such;  not good for environment vars.

Best place to set environment variables is /etc/profile
(system wide)  or  $HOME/.profile  (per user).   TWO PROBLEMS
that need to be solved at each local system.   First,  CSH
and its variants will not source either of these.   But you
can trick CSH (and TCSH and whatever others there are) to get
the effect.   Second,  graphical start-up does not usually source
$HOME/.profile because it may historically be ... "interactive".
(And would be isolated to one terminal window at best.)

If your $HOME/.profile is not interactive,  then your
graphical start-up should be adjusted to source it.
If your $HOME/.profile is interactive,  you need to change that.
(Better behaviour:  Let it sense whether or not there is a TTY
and drive another script for any interactive work.)

SUMMARY

        All "profile" scripts should be made to accomodate
        batch or non-interactive work.

        CSH and TCSH and all C-Shell variants need to source
        the Bourne shell variants /etc/profile and $HOME/.profile
        isolating system and user customizations to one file,
        reducing config scatter.

        Environment vars should be set  (or concatenated)
        (and then exported)  in the profiles so that they
        are set ONCE per session.

        Command aliasing and other per-instance work may then
        be left in $HOME/.bashrc  (and corresponding RC scripts
        for things other than BASH).

I can demonstrate each of these,
but it may be more traffic than the list wants at this time.
(I feel a blog coming on!)

-- R;

On Thu, 27 Oct 2005, Tom Duerbusch wrote:

> Suse 9 (64 bit) and the installation of Oracle 10g....
>
> Using the Installation manual from Oracle, I installed Oracle 10g on
> SLES9 with SP2.  At least I think I followed it correctly.
>
> Per the Oracle documentation, I had to interactively set a bunch of
> environment variables and "export" them.
>
> However, when I logoff the user Oracle, and log back on again (or after
> a Linux reboot), these variables are not set.  At reboot, the database
> doesn't come back up, and I get "command not found" when trying to do
> "sqlplus".
>
> Now if I reset the variables, I can get to "sqlplus".  Oracle still
> doesn't come up.  I currently suspect that the process that brings up
> Oracle, also needs to know these environment variables to show the
> location of the Oracle bin files as well as where the database files are
> located.
>
> So, that's the problem.  Nothing in the Oracle Installation manual deals
> with the saving of these variables.  It may be that it is doing them
> under the covers in some way, that failed.
>
> Now, in the IBM Redbook, User experiences with Oracle 10g, which also
> deals with the installation of Oracle 10g under SLES9, it does show
> putting these variables in a .profile file in the Oracle userid...
>
> Tried that, didn't work.  Apparently, .profile isn't being executed.
> The file that should be executed is the .bashrc file.
>
> Hummmmm......
>
> OK, the IBM manual didn't say what shell it was using.
> The Oracle manual said that it was using the bash shell, but didn't say
> anything about .profile or .bashrc.
>
> Or perhaps there is a third side to this.  Is there an automagical
> thingie that saves environment variables across boots that is either
> triggered by, perhaps the export command, or a file that is kept that
> sets these variables "system wide" that the Oracle Install process might
> have changed?
>
> Or a final perhaps, that it is normal for a Linux systems programmer (is
> there a systems programmer title in the Linux world?), to just know that
> some things must be put in certain files (.profile or .bashrc, or ...)
> and that because it is normal, no one needs to document such actions?
>
> Just looking for a general direction to follow.  (that is unless someone
> has the real answer for this<G>)
>
> So far, the Oracle Discussion groups in the Oracle website, doesn't seem
> to know much, yet).
>
> Thanks
>
> Tom Duerbusch
> THD Consulting
>
> ----------------------------------------------------------------------
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
>

----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Reply via email to