Rick Troth wrote:
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.)
Syrup pls.
Don't go changing /etc/profile. The correct place (on RH and probably
SuSE, Man* etc) is /etc/profile.d for global stuff. See examples already
there.
Red Hat ships .bash_profile. I suspect bash does not read ~/.profile if
.bash_profile exists, and this goes to explain the apparent ignoring of
~/.profile already mentioned.
~/.bashrc is read only by interactive shells (but not those invoked as
sh). I'm looking at the man page.
I think making csh read sh initialisation files is a Bad Idea(TM). I've
not used csh for more than a couple of minutes, but documentation I've
read suggests its syntax is different. /etc/profile.d on my systems has
different files for each.
My default, bash reads profiles when invoked as a login shell, but not
otherwise.
Here's a quote from the man page:
When bash is invoked as an interactive login shell, or as a
non-interactive shell with the --login option, it first reads and
executes commands from the file /etc/profile, if that file exists.
After reading that file, it looks for ~/.bash_profile, ~/.bash_login,
and ~/.profile, in that order, and reads and executes commands from the
first one that exists and is readable. The --noprofile option may be
used when the shell is started to inhibit this behavior. When a login
shell exits, bash reads and executes commands from the file
~/.bash_logout, if it exists.
There's much more there. It goes on to say that bash does not
necessarily read any initialisation files.
<snip>
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.
I have the impression (from the db2 installation scripts and some
comments I've seen) that IBM uses csh by default on AIX.
I suspect other vendors (including ISVs) have other ideas, and that
documentattion written for some kinds of Unix is ported to Linux without
taking into account such differences as the default shell, and without
properly testing that the instructions actually work.
Probably, competant Linux sysadmins tend to splutter, reach for their
favourite elixir, and get on with it.
I suggest that when you identify the problem, you report it as a bug in
the hope it will actually get fixed.
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?
state is not saved in this way; often it would be undesirable.
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?
Certainly a capable sysadmin should be able to make the necessary
translations.
I know this implies things about your skills, but then we all started
ignorant. I remember my first contact with Linux, when I telnetted to my
IAP from my OS/2 system and floundered.
--
Cheers
John
-- spambait
[EMAIL PROTECTED] [EMAIL PROTECTED]
Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/
do not reply off-list
----------------------------------------------------------------------
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
