0

Our programming environment is dependent upon certain environment variables being set. For example, to use distcc, one needs to define the DISTCC_HOSTS environment variable. The way we handle this is forcing each developer to source a global tcshrc file upon invoking a new shell. The global tcshrc file contains statements to set the environment variables up (among other things).

However, this is awfully discriminatory as each developer is forced to use tcsh since setting an environment variable is different per shell.

The most obvious solution to this problem to have corresponding global bashrc and zshrc files, but that of course becomes cumbersome since now we have to maintain three different files all containing the same logic.

Are there any clean solutions to solve this sort of situation?

|improve this question
  • why do you need to support multiple shells? – Pemdas Jan 21 '11 at 4:05
  • @Pemdas - because we are essentially forcing a developer to use tsch to work which may or may not be the shell of choice for him/her. – user13830 Jan 21 '11 at 4:09
  • 2
    Isn't .profile read by all the shells? And shouldn't this be on unix.stackexchange.com or ubuntu.stackexchange.com ? – TheLQ Jan 21 '11 at 4:12
  • 2
    Why can't each developer who doesn't want to use tcsh configure his/her own environment? Setting environment variables isn't hard. – Adam Lear♦ Jan 21 '11 at 4:26
  • @Anna Lear - Because we can several environment variables to have a complete development environment. Setting the DISTCC_HOSTS variable was one of many environment variables that must be set to make sure that each developer is on the same page. If we decided that we needed to add an additional environment variable, then every developer has to make corresponding changes which violates the Don't Repeat Yourself principle. – user13830 Jan 21 '11 at 4:35
3

Once you have source the global tcshrc (which you should not need to do (put some commands in $(HOME)/.tcshrc to do the work)).

All you have to do is start your favorite shell.
Your shell will then inherit all the environment from its parent.

> source /bla/tcshrc
> bash
bash >

In-fact you can do this all in your .tcshrc file:

# Set up your environment
source /bla/tcshrc
# Start your favorite shell here
bash
# When bash exits this shell exits.
# I would not do this last line but for compleness
exit
|improve this answer
  • Curious about the downvote. If there is something that does not work I would like to know. – Martin York Jan 29 '11 at 6:40
1

You could write a script that contains the environment information and generates the correct .whatever for the corresponding shell.

|improve this answer
1

A simple solution would be to use some neutral format for environment variable definitions, e.g. in some file env.file

VARIABLE value

and to generate the setup scripts for different shells automatically, e.g. for bash

awk '{ print "export "$1"="$2 }' < env.file > bashrc

or for tcsh

awk '{ print "setenv", $1", "$2 }' < env.file > tcshrc

This seems to actually be one of cases where a programmatic solution does solve a social problem.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy