Forum OpenACS Q&A: wrong PATH for postgres following installation doc -PLS HLP
At point 3 (Set up postgres's environment variables); I follow the direction but when checking env I get:
Am I doing something wrong?
Thank for any help.
for a reason or another .bashrc wasn't run when login.
Something like this at the top of .bash_profile help, usually:
# source .bashrc if one exists
if [ -f ~/.bashrc ]; then . ~/.bashrc; fi
The ambuguity comes from the fact that with the changes applied to .bashrc only, and no sourcing of it in .bash_profile, yet checking the environment when logging in as nsadmin (running bash as login shell) -- changes don't get reflected.
Adding that single line to .bash_profile never hurts, and we should probably add that to the docs -- with or without it when nsd is started things will suddenly just work.
Another thing to add to docs could be a reference to bash(1) man page, as well as references to any other useful manual pages.
All the environment changes could also be made in nsd-postgres or nsd-oracle shell scripts (if they are still included in docs, not sure about it), as long as they are exported.
What you really want is a file called
/etc/profile-postgres.sh or something like that. It
should be something like this:
# # $Id: profile-postgres.sh,v 1.2 2002/12/24 07:03:13 atp Exp $ # # Single central place for setting all PostgreSQL environment variables. # Source this from /etc/profile. # # --firstname.lastname@example.org, 2002/12/06 14:03 EST # For Debian PostgreSQL package: LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/postgresql/lib/ PATH=$PATH:/usr/lib/postgresql/bin/ PG_HEADERS=/usr/include/postgresql ## For locally installed from source PostgreSQL: #LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/pgsql/lib #PATH=$PATH:/usr/local/pgsql/bin export PATH LD_LIBRARY_PATH PG_HEADERS . /etc/postgresql/postgresql.env
Then do this in an appropriate spot in your system-wide
for script in /etc/profile-oracle.sh /etc/profile-postgres.sh do if [ -e "$script" ] then . "$script" fi done
Isn't it only _wrong_ until you have two versions of postgresql running? I liked your suggestion when you made it a while ago for Oracle install, but then I immediately installed two different copies of pg.
It seems that if you want to get technical about things, environment variables should be set per process, whenever a process is started up, or restarted.
However, each instance of a service (e.g. eache separate postmaster process or aolserver proces -- whatever) should include 'tweaking' of environment as and when required.
For example, you may want to run 2 Pg's, listening on different ports (could be set as a env. variable and used in postmaster.conf), using different PG_DATA. Yet they both may be the same Pg version, hence use the same libe (PG_LIB) and binaries (PG_BIN or whatever), ahve access to the same system binaries (PATH), etc.
Clients using one instance or another source the appropriate script. Your only decision to make, is if one instance should be the default - if so, source that instance's profile-postgres.sh from /etc/profile, and not the other. If you don't want any default instance, then source neither script from /etc/profile - now in order to use the database, each client must take a explicit action. But that action is just sourcing the script. This is way I said to put the settings into profile-postgres.sh, not directly into /etc/profile.
Having two instances changes nothing important - these are still system-wide settings that should be in a system-wide place. What you want to avoid is having the exact same settings hard-coded into lots of different places - put each in one place only, whenever feasible.
So that's good, there's no magic going on behind the scenes, it is just good old /etc/profile doing the work. Very simple.for i in /etc/profile.d/*.sh ; do if [ -r "$i" ]; then . $i fi done unset i
(I guess nobody in the Linux world worries about /bin/sh vs. /bin/bash differences anymore, since most Linux distributions use bash for everything. That "; then" syntax won't work in sh, like you sometimes find on Solaris...)
Thanks Andrew, I knew you had a good, I mean very good, explanation!