Cameron Hutchison wrote:
A program must not depend on environment variables to get reasonable
defaults. (That's because these environment variables would have to
be set in a system-wide configuration file like `/etc/profile', which
is not supported by all shells.)
Sorry for the late response on this. There were the problems with debian-user, and then I got busy with work.
Slackware handles this "multiple shells" situation by sourcing "/etc/profile.d/*.sh" if you're using a (ba)sh-compatible shell and "/etc/profile.d/*.csh" if you're using a csh-compatible shell. Packages that need to set environment variable information must supply both the "sh" and "csh" versions. This has always seemed like a decent solution to me (it gets the job done), of you exclude the fact that I end up having to make sure all my x terminals run login shells.
If there are other shells out there that aren't compatible with (ba)sh or csh, you could throw them into the mix as well ("/etc/profile.d/*.whatever").
> It is an excellent way for optional packages to announce their presence by
> setting appropriate variables: CLASSPATH for java for example.
I was actually looking for a clean way to set ${JAVA_HOME} and add "${JAVA_HOME}/bin" to my path. There are lots of files in "${JAVA_HOME}/bin" (15 or 20 all told), and I don't believe it makes sense for me to create wrappers for all of them.
I respect the established Debian policy...but I do disagree. I think it is possible to build an environment-variable-setting system that works with multiple shells, like the one currently in Slackware.
--j
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
