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

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

  • 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. Jun 7 '17 at 18:38

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.)
  • 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. Jun 7 '17 at 18:38
  • You may need to install the redhat-lsb-core package. Jul 3 '17 at 14:55
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.

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

Use rpm -q 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.

  • 1
    Did you mean rpm -qa instead of rpm -q? Using -q by itself requires a query argument. 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 Mar 20 '18 at 18:38

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


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.

  • 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



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:


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.

  • 2
    -1. Admin can decide to update kernel just as easily. 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 }')

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

cat /etc/system-release-cpe | cut -d ':' -f5
  • 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

user7610's answer works but this will fail when release has minor version as well. For example, I have a Redhat 5 with el5_11.

# rpm -q --queryformat '%{RELEASE}' rpm
# rpm -q --queryformat '%{RELEASE}' rpm | grep -o [[:digit:]]*\$

I tried the user7610 and Brād solutions combinedly. That solved my problem for a common script for all RHEL versions.

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

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.