The Limits of Standard Text Editors
If you are a Linux system administrator troubleshooting a broken bash script or a corrupted configuration file, you typically open the file using a standard text editor like nano, vim, or simply print the output to the screen using cat.
However, computers do not read English letters; they read raw bytes. Sometimes, a text file contains hidden, non-printable characters—such as rogue carriage returns (\r), weird null bytes (\0), or bizarre Unicode formatting errors caused by copying and pasting code from a messy website.
Standard text editors will completely hide these rogue characters, or display them as generic white spaces. Your script will crash, the code will look perfectly fine on your screen, and you will spend hours tearing your hair out. To truly see exactly what is inside a file at the raw byte level, you must use the od (Octal Dump) command.
Step 1: The Basic Octal Dump
The od command is designed to bypass text encoding entirely and dump the raw binary data of a file directly to your terminal screen. By default, it translates this binary data into Octal (base-8) numbers.
If you have a file named config.txt, run:
od config.txt
The output will look like a matrix of seemingly random numbers (e.g., 0000000 064150 062554 020157 067167 071162). The very first column represents the file offset (how far into the file you are), and the subsequent columns are the raw octal values of the data.
While this is what computers like to see, it is nearly impossible for a human to read.
Step 2: Translating to Human-Readable Characters
To make the output useful for debugging a broken script, you need to map those raw octal numbers back into printable ASCII characters, while specifically highlighting the invisible control characters.
You do this using the -c (character) flag.
od -c config.txt
The output will now display standard English letters. More importantly, it will explicitly spell out every single invisible character. Instead of a blank space, you will literally see \n (newline) or \t (tab) printed on the screen.
If you copied a script from a Windows machine to a Linux server, and it keeps crashing, od -c will instantly reveal that every line ends with an invisible Windows carriage return (\r \n) instead of a standard Linux newline (\n).
Step 3: Dumping in Hexadecimal (Base-16)
While octal (base-8) is the historic Unix standard, most modern programmers and reverse-engineers prefer to read raw data in Hexadecimal (base-16).
You can force the od command to output a standard hex dump using the -x flag.
od -x config.txt
This will translate the raw data into standard hex pairs (e.g., 6865 6c6c 6f20 776f 726c 640a).
Step 4: The Ultimate Debugging Format
If you are dealing with a truly corrupted binary file, the most efficient way to troubleshoot it is to display the hexadecimal output and the ASCII character output side-by-side simultaneously.
You can achieve this by stacking the formatting flags using the -t (type) flag, asking for both hexadecimal (x1) and characters (c).
od -t x1c config.txt
The terminal will output two rows for every block of data. The top row will show the precise hexadecimal value of the byte (e.g., 68), and the bottom row will show the human-readable ASCII equivalent (e.g., h), perfectly aligned. This allows you to instantly pinpoint exactly which byte is corrupted without needing to memorize the entire ASCII conversion table.