Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|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. –  Anna 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
show 1 more comment

3 Answers

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
share|improve this answer
    
Curious about the downvote. If there is something that does not work I would like to know. –  Loki Astari Jan 29 '11 at 6:40
add comment

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

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.