Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I work in an environment where we are slowly transitioning machines from Red Hat Enterprise Linux 5 to RHEL 6.

I need some of my scripts to do something subtly different on RHEL6 machines to what is currently being done on RHEL5 machines.

The pragmatic solution is to check at runtime and run some commands on RHEL5, others on RHEL6 and some on both.

A practical example of this is that we are using environment modules and my .bashrc includes a module load git line, but on RHEL6 machines this command errors:

RHEL6 system, git should be installed - not loading module

Looking in the modulefile I find the following code:

set redhatrelease [eval exec "cat /etc/redhat-release"]
if { [regexp -nocase {release 6} $redhatrelease] } {
  puts stderr "\n\t RHEL6 system, git should be installed - not loading module\n"
} else {

This seems to do what I want, but I was hoping for something shorter.

So, what is the easiest way to tell RHEL5 from RHEL6 in a bash script?

Ideally it should be robust across different major versions, but be tolerant of variations in minor release numbers.

share|improve this question
does lsb_release work? (-r ought to give you just the number; try also -a to see everything available) If so, that's also cross-vendor. – derobert Nov 29 '12 at 19:55
Test for features, not platforms. Your platform test today will break when RHEL7 comes out, and may break before that when RHEL 6.next comes out, perhaps because they forward ported an EL5 feature to 6.x to silence complaints about it being removed. So, if your script needs a git Bash module, you check whether it exists before calling it. When/if it appears later, your check's results change, so suddenly the feature starts working, without any extra effort. – Warren Young Nov 29 '12 at 21:29
@WarrenYoung - Thanks, but I'm not a sysasmin here, just a user of a centrally managed RHEL deployment. All of our RHEL5 machines are essentially the same image, ditto all RHEL6 machines, so for me knowing the major revision is sufficient. Given that we are only in the planning stages of moving to RHEL6 now, I think it will be a while before we have to worry about RHEL7. *8') – Mark Booth Nov 30 '12 at 9:53
@derobert - No, on RHEL5 & 6 lsb_release -r includes other text too, e.g. Release: 5.8. As Dennis Kaarsemaker explains though, if you use lsb_release -rs instead, you get just the number. – Mark Booth Nov 30 '12 at 9:57
See also serverfault.com/questions/89654/what-version-of-rhel-am-i-using - there's a tip for doing it with RPM when lsb is not installed. – Dan Pritts Aug 15 '14 at 18:36
up vote 3 down vote accepted

You can also use the lsb_release command. If you're already certain it's RHEL, getting the major version number is:

majversion=$(lsb_release -rs | cut -f1 -d.)
share|improve this answer
Works on Centos and Redhat proper, fails on Oracle Linux release of Redhat. lsb_release not found. – user959690 Jul 20 at 20:12
if grep -q -i "release 6" /etc/redhat-release
  echo "running RHEL 6.x"

This would be the simplest way I can think of.

share|improve this answer

You could expand on this for multiple Linux distros by using the /etc/issue file instead of /etc/redhat-release file.

share|improve this answer

All of the methods mentioned here rely on text files, and as such could be misleading. Someoune with the right access may change the contents of /etc/redhat-release, /etc/issue, etc. even to just obfuscate this information. A more reliable method would involve knowing the kernel releases usually provided by Red Hat on each version of RHEL:

  • RHEL4 uses kernel 2.6.9-X
  • RHEL5 uses kernel 2.6.18-X
  • RHEL6 uses kernel 2.6.32-X
  • RHEL7 uses kernel 3.10.0-X

invariably up until now, you can find out the running kernel release by running uname -r. You may get fancier by running something along the lines of

uname -r | awk -F- '{print $1}'

This would give the specific information about the kernel, as in the above table. You might be able to drive parallels to other distributions, if they consistently use kernel releases.

share|improve this answer
-1. Admin can decide to update kernel just as easily. – Oliver Gondža Nov 13 '15 at 8:38

I ended up using jordanms answer, but adding a twist of my own.

Because I didn't want to have all of my rhel6 commands together and all of my rhel5 commands together, but interleaved within their own section, and I didn't want to have to replicate this code every time I wated to switch, instead I did this:

if   grep -q -i "release 6" /etc/redhat-release ; then
elif grep -q -i "release 5" /etc/redhat-release ; then
  echo "Running neither RHEL6.x nor RHEL 5.x !"

That way, I could do things like:

[ $rhel5only ] && module load java/6
[ $rhel6only ] && module load java/7

# Eclipse
module load eclipse

# Python
[ $rhel5only ] && module load python/2
[ $rhel6only ] && module load python/3


share|improve this answer

if your further intention is to manage modulefiles on per context-basis, I suggest you check out EasyBuild and some related logic, living in Python format:

share|improve this answer

Your Answer


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

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