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.

  • 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

11 Answers 11


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.)
| improve this answer | |
  • Works on Centos and Redhat proper, fails on Oracle Linux release of Redhat. lsb_release not found. – user959690 Jul 20 '16 at 20:12
  • This answer seems outdated now. I only find lsb_release on my RHEL/CentOS 5 machines. It's nowhere to be found on 6 or 7. – Dale Anderson Jun 7 '17 at 18:38
  • You may need to install the redhat-lsb-core package. – Dennis Kaarsemaker Jul 3 '17 at 14:55
if grep -q -i "release 6" /etc/redhat-release
  echo "running RHEL 6.x"

This would be the simplest way I can think of.

| improve this answer | |
  • Works for every variation of CentOS and RHEL i have in my inventory from 5 through 7, unlike lsb_release which only seems to work for 5. – Dale Anderson Jun 7 '17 at 18:38

Use rpm -q |grep redhat-release-server

The /etc/redhat-release file could have been edited by an admin looking to install third party software without performing an actual OS upgrade.

| improve this answer | |
  • 1
    Did you mean rpm -qa instead of rpm -q? Using -q by itself requires a query argument. – Dale Anderson Jun 7 '17 at 18:51
  • @Dale Anderson, thank you, this is the only one that worked for me, on 7.4, and I didnt know it as 7.4 until i ran this with -qa – Brian Thomas Mar 20 '18 at 18:38
major_version=$(rpm -q --queryformat '%{RELEASE}' rpm | grep -o [[:digit:]]*\$)

rpm -q --queryformat '%{RELEASE}' rpm prints something like 25.el7. Then it is just matter of taking the last digit(s). Tested on RHELs 5,6,7 and Fedora 24.

As others pointed out, lsb-version may not be installed. Additionally, there is at least one RHEL5 system that does not have the redhat-release-server package installed.

| improve this answer | |
  • thank you, this should be upvoted, as it always works and exactly returns the desired number. – phiphi Oct 2 '17 at 13:37

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

| improve this answer | |

Here is another, more precise way to get this result. The kernel packages in RHEL have the string 'elN' included, where N would represent the major version of the OS. Thus, one could run the following command to identify the version of RHEL:

# uname -r | sed 's/^.*\(el[0-9]\+\).*$/\1/'

This would return a string, "el5", "el6" or "el7", depending on the matching string on the given host.

| improve this answer | |
  • I'm using a mix of CentOS and RedHat, versions 5-7, and the answer actually works on all versions: uname -r | sed 's/^.*(el[0-9]\+).*$/\1/' – WallStProg Sep 5 '18 at 20:30

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


| 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:

| 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.

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

RHEL 6 has added the /etc/system-release-cpe file. This contains a :-separated string that may look something like

# cat /etc/system-release-cpe

Now it is enough to pull fields $5 and $7 to get RHEL version and RHEL variant.

# will be 7 or 6, does not work for 5 as file is missing there
RHEL_VERSION_MAJOR=$(cat /etc/system-release-cpe | awk -F: '{ print $5 }' | grep -o ^[0-9]*)
RHEL_VARIANT=$(cat /etc/system-release-cpe | awk -F: '{ print $7 }')
| improve this answer | |

Starting from RHEL 6, the most concise way would be:

cat /etc/system-release-cpe | cut -d ':' -f5
| improve this answer | |
  • If that was to be "most concise" you'd do cut -d: -f5 /etc/system-release-cpu and avoid the UUOC. However, the question was asking about transitioning from RHEL 5 to 6. If this only works from RHEL 6 onwards doesn't it fail to satisfy the question requirements? – roaima Dec 15 '17 at 22:12

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.