I login to a system that reads my bashrc file and loads some software ready to use.

I'd like to load a given bashrc file depending on the linux system that I am logging into.

Specifically, if I am logging into a system with centOS 6, I'd like to load my centos6 bashrc:

cat /etc/*-release
CentOS release 6.4 (Final)
CentOS release 6.4 (Final)
CentOS release 6.4 (Final)

and if I am logging into a system with centOS 5.7, I'd like to load my centOS 5.7 bashrc.

cat /etc/*-release
CentOS release 5.7 (Final)

I am thinking along the lines of having 3 bashrc files in my home dir:

.bashrc with an if condition such that if finds that I was logging in into centOS6 would run,

source ~/.bashrc.centos6

and an else, such that if finds that I was logging in into centOS5.7 would run,

source ~/.bashrc.centos5

So I guess my .bashrc code would look kind of like this:

if cat /etc/*-release == "CentOs release 6.4"
   source ~/.bashrc.centos6
elif cat /etc/*-release == "CentOs release 5.7"
   source ~/.bashrc.centos5

I am still new to bash scripting so I have no idea how I'd do that and if its a god way to go to achieve my goal.

  • Learn more about grep as well as shell command return values and the && operator. – Pavel Šimerda Apr 5 '14 at 21:54

Using the lsb_release command (should be in most distros by default):

shopt -s nocasematch

if [ -x "$(which lsb_release)" ]; then
  case "$(lsb_release -si)" in
      case "$(lsb_release -sr)" in
          source ~/.bashrc.centos5.7
          # source something for any other version 5 minor release
          source ~/.bashrc.centos6

shopt -u nocasematch

Depending on the exact output of lsb_release -si and lsb_release -sr. You can add more cases as needed.

| improve this answer | |
  • More portable than /etc/*release? – mikeserv Apr 5 '14 at 22:22
  • @mikeserv, maybe if you used /etc/*release /etc/*[-_]version, this would be more portable. – Graeme Apr 5 '14 at 22:27
  • I dunno, but if I do lsb_release I get "n\a" whereas cat /etc/*release gives me a whole slew of information - this guy just taught me that by the way. And you just taught me about lsb_release. – mikeserv Apr 5 '14 at 22:30
  • 1
    @Dnaiel, oops, missed an esac. Should be fixed now. – Graeme Apr 6 '14 at 22:19
  • 1
    @Dnaiel, my bad, it should have been nocasematch instead of nocaseglob. Updated. – Graeme Apr 9 '14 at 16:29

This is a perfect use-case for ${parameter+substitution} since we're talking about parameters after all.

  _src_release() {
     . ${RELEASE:=/path/to/fallback}
      } <<GET_RELEASE
         ${PREFERRED="$(whatever gets you /path/to/preferred)"}
         ${NEXT_BEST="$(something else gets you /path/to/next/best)"}
         ${IF_YOU_MUST="$(get /the/third/option)"}

You could also do all of the logic in a for loop in command substitution then just echo the results out into $RELEASE when you get it. The point of this is that the variable can test its own value if you use it correctly.

So when you .dot source $RELEASE if none of those variables set in its input have been populated with other than NULL values it will just . /path/to/fallback.

You can do as many of those as you like in that fashion, but also a || short-circuit test just following the shell's .dot statement above will handle its errors - this is really easy to use - and you can it look and mean like what it does, which can be helpful.

That's if you wanna do it in .profile, but I suspect the best way is in /etc/login.defs with $ENV_PATH or /etc/passwd. For each distro that you want to login to you could either create a special link that will only $PATH for that specific distro or specifically set the shell executable to be a wrapper script for what you want. That way it is actually is handled by the login daemon and not by subvertible profile scripts.

| improve this answer | |

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.