>>>>> "Greg" == Greg Fall <[EMAIL PROTECTED]> writes:
> On Sat, 23 May 1998, David Masterson wrote:
>>> Set the xdm resources like this in /etc/X11/xdm/xdm-config:
>>> DisplayManager._0.userPath: \
>>> /usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin/:\
>>> /usr/bin/mh:
>>> DisplayManager._0.systemPath: \
>>> /usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:\
>>> /usr/X11R6/bin:/usr/bin/mh:
>> What's the difference between setting this in xdm-config and
>> setting it in Xresources?
> Maybe nothing; besides xdm-config being system-wide and controlled
> by root and ~/.Xdefaults up to the discretion of each user. I guess
> it ought to work. Only one way to find out...
No, I meant Xresources which is also in /etc/X11/xdm. This file is
also system wide and controlled by root. I'm not really sure which is
the best place to set the PATH: xdm-config, Xresources, or Xsession.
>>> In /etc/skel/.bash_profile, take PATH=$PATH:$HOME/bin out (along
>>> with the PATH part of the export that follows), and put it in
>>> /etc/skel/.bashrc, like this:
>>> export PATH=$PATH:$HOME/bin
>> Isn't .bashrc run by every non-login bash? Therefore, doesn't this
>> imply that every subshell will have its PATH variable updated such
>> that after these commands:
>> $ bash
>> $ bash
>> $ bash
>> the PATH will be $PATH:$HOME/bin:$HOME/bin:$HOME/bin ??
> I think so. The way I really have it in my ~/.bashrc is this:
> if [ -z "`echo $PATH | gerp $HOME/bin`" ]; then export
> PATH=$PATH:$HOME/bin fi
Wasteful. This is done witb every subshell invocation. Simply set
the PATH variable in .bash_profile and forget about the if-test.
BTW, personally, for non-root accounts, I'd put the $HOME/bin at the
beginning of the PATH so that I could easily override a system command
with my own version if necessary. Sometimes its useful to be able to
wrap a system command in a shell wrapper to have it do other things.
>> I know a lot of people set environment variables in the bashrc file
>> (or cshrc file for CShell users). IMHO, this is bad practice as it
>> can lead to unexpected happenings when you (for testing purposes)
>> set an environment variable (by hand or special command), only to
>> have the bashrc file set it back to your default in a subshell (or
>> made very long thru addition as in the above).
> I agree; environment variables seem like a lazy way out and make a
> big mess. I'm always disappointed when I install an application and
> discover that it depends on some new environment variable, because
> that means every user needs the information, and needs to putz
> around with their ~/.bashrc or what have you, before they can try it
> out. Commercial software I've bought for my system has been
> notorious for requiring this step.
Simple rule -- set environment variables in .profile/.login files.
--
David Masterson
[EMAIL PROTECTED]
--
PLEASE read the Red Hat FAQ, Tips, Errata and the MAILING LIST ARCHIVES!
http://www.redhat.com/RedHat-FAQ /RedHat-Errata /RedHat-Tips /mailing-lists
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject.
