How to tell if a Linux system is big endian or little endian?

On a Big Endian-System (Solaris on SPARC)

$ echo -n I | od -to2 | head -n1 | cut -f2 -d" " | cut -c6 

0

On a little endian system (Linux on x86)

$ echo -n I | od -to2 | head -n1 | cut -f2 -d" " | cut -c6 

1

The solution above is clever and works great for Linux *86 and Solaris Sparc.

I needed a shell-only (no Perl) solution that also worked on AIX/Power and HPUX/Itanium. Unfortunately the last two don't play nice: AIX reports "6" and HPUX gives an empty line.

Using your solution, I was able to craft something that worked on all these Unix systems:

$ echo I | tr -d [:space:] | od -to2 | head -n1 | awk '{print $2}' | cut -c6

Regarding the Python solution someone posted, it does not work in Jython because the JVM treats everything as Big. If anyone can get it to work in Jython, please post!

Also, I found this, which explains the endianness of various platforms. Some hardware can operate in either mode depending on what the O/S selects: http://labs.hoffmanlabs.com/node/544

If you're going to use awk this line can be simplified to:

echo -n I | od -to2 | awk '{ print substr($2,6,1); exit}'

For small Linux boxes that don't have 'od' (say OpenWrt) then try 'hexdump':

echo -n I | hexdump -o | awk '{ print substr($2,6,1); exit}'

If you are on a fairly recent Linux machine (most anything after 2012) then lscpu now contains this information:

$ lscpu | grep Endian
Byte Order:            Little Endian

This was added to lscpu in version 2.19, which is found in Fedora >= 17, CentOS >= 6.0, Ubuntu >= 12.04.

Note that I found this answer from this terrific answer on Unix.SE. That answer has a lot of relevant information, this post is just a summary of it.

Here is a more elegant python one-line script

python -c "import sys;sys.exit(0 if sys.byteorder=='big' else 1)"

exit code 0 means big endian and 1 means little endian

or just change sys.exit to print for a printable output

You can take advantage of ELF file format to determine the endianness of your system. For example, print the first six bytes of an arbitrary ELF file in hex:

xxd -c 1 -l 6 /bin/ls

0000000: 7f  .
0000001: 45  E
0000002: 4c  L
0000003: 46  F
0000004: 02  .
0000005: 01  .

If the last line (the sixth byte) is 01, according to ELF format, 01 is little endian and 02 is big endian.

If you haven't got an xxd on your box (and do have busybox), try this:

hexdump -s 5 -n 1 -C /bin/busybox

The main answer can be simplified slightly using awk:

On a Big Endian system (Solaris, SPARC)

$ echo -n I | od -to2 | awk 'FNR==1{ print substr($2,6,1)}'
0

On a Little Endian system (Linux, Intel)

$ echo -n I | od -to2 | awk 'FNR==1{ print substr($2,6,1)}'
1

Newer Linux Kernels

As of version 2.19 of the util-linux package the command lscpu started including a field related to Endianness. So now you can simply use this command to find this out:

$ lscpu | grep -i byte
Byte Order:            Little Endian

This has been confirmed on Ubuntu 12.10 and CentOS 6. So I would be willing to assume that most 3.0+ Linux Kernels are now offering this.

On Debian/Ubuntu systems you can also use this command, not sure of when it became available:

$ dpkg-architecture | grep -i end
DEB_BUILD_ARCH_ENDIAN=little
DEB_HOST_ARCH_ENDIAN=little

References

• Is there a system command, in Linux, that reports the endianness?

This Python script should work for you:

#!/usr/bin/env python
from struct import pack
if pack('@h', 1) == pack('<h', 1):
    print "Little Endian"
else:
    print "Big Endian"

python -c "import sys; print(sys.byteorder)"

It would print the endianess of the system.

I found a way to do it in Jython. Since Jython (Python on the JVM) runs on a VM, it always reports big endian, regardless of the hardware.

This solution works for Linux, Solaris, AIX, and HPUX. Have not tested on Windows:

    from java.lang import System
    for property, value in dict(System.getProperties()).items():
        if property.endswith('cpu.endian'):
            return value

A single-line command based on ELF format:
hexdump -s 5 -n 1 /bin/sh

Slightly different requirement: I need a test like this in a program build configure script to determine whether the compile target machine is bit or little endian, without executing code. The script must deposit #define HAVE_LITTLE_ENDIAN 1 into a config.h header, or else #define HAVE_LITTLE_ENDIAN 0.

The compile target machine may be different from the build machine, since we may be cross-compiling, which also explains why the test mustn't try to run any compiled code. It is out of the question to have a little C program with a printf statement that spits out the answer.

A possible solution is this. We generate a file called conftest.c which contains this:

#define USPELL(C0, C1, C2, C3) \                                             
  ((unsigned) C0 << 24 | \                                              
   (unsigned) C1 << 16 | \                                              
   (unsigned) C2 << 8 | (unsigned) C3)                                       

unsigned x[6] = {                                                       
  0,                                                                         
  USPELL('L', 'I', 'S', 'P'),                                                
  USPELL('U', 'N', 'I', 'X'),                                                
  USPELL('C', 'O', 'R', 'E'),                                                
  USPELL('D', 'W', 'I', 'M'),                                                
  0                                                                          
};

Now, we compile this to conftest.o using:

$ /path/to/cross-compiling/cc conftest.c -c

Then we run:

$ strings conftest.o
PSILXINUEROCMIWD

If the string PSILXINUEROCMIWD occurs, the target is little-endian. If the string LISPUNIXCOREDWIM occurs, it is big-endian. If neither string occurs or, even more astonishingly, both do, then the test has failed.

This approach works because the "fourcc" constants calculated in the program have machine-independent values, denoting the same integers regardless of endianness. Their storage representation in the object file follows the endianness of the target system, and that is visible via the character-based view under strings.

The two zero guard words ensure that the string is isolated. That isn't strictly necessary, but it ensures that the string we are looking for is not embedded in some other string, meaning that strings will output it on a line by itself.

P.S. the USPELL macro doesn't parenthesize the argument insertions because it's crafted for this specific purpose, not for re-use.