What is the difference between the od, hd, hexdump and xxd commands ? They are all commands for dumping files and they can all dump it in various formats such as hexadecimal, octal or binary. Why creating different programs ?

Using Solaris 10 ipsec the key must be converted in hex format. So I need a command to convert text in hex. This line works fine echo "mypassword" | od -t x1|head -1|tr -d ' ' |tr [a-z] [A-Z] Produce 00000006D7970617373776F72640A Anyway using an online converter it return this 6D7970617373776F72640A As a workaround I use this echo "mypassword" | od -t x1|head -1|tr -d ' ' |cut -c 8-1000|tr [a-z] [A-Z] it return 6D7970617373776F72640A The question is..why od return those 00000000?

## Busybox The [Busybox documentation](https://busybox.net/downloads/BusyBox.html) explains only this: > od [-aBbcDdeFfHhIiLlOovXx] [-t TYPE] [FILE] > > Write an unambiguous representation, octal bytes by default, of FILE to standard output. With no FILE or when FILE is -, read standard input. But it doesn't explain what each option is and they seem to be really different from the [man page](https://man7.org/linux/man-pages/man1/od.1.html) The -t option seems to not exist and gives the error:

od: invalid option -- 't'

BusyBox v1.35.0 () multi-call binary.

Usage: od [-aBbcDdeFfHhIiLlOovXx] [FILE]

The other [documentation website](https://boxmatrix.info/wiki/Property:od) seems to ommit the -t option and seems more accurate. > Usage: >

> od [-abcdeFfhiloxsv] [FILE]
>

> Print FILE (or stdin) unambiguously, as octal bytes by default Confirming the online documentation, when the command od --help is sent, the output is: >Usage: od [-aBbcDdeFfHhIiLlOovXx] [FILE] ### Repository So looking at the [source code](https://github.com/mirror/busybox/blob/master/coreutils/od.c) it seems to be some kind of remap to the od_bloaty.c [source file](https://github.com/brgl/busybox/blob/master/coreutils/od_bloaty.c) ### Question I could not understand this source file and the documentation is not clear on all the options of the od command. Is there some other documentation for this busybox command or some better explanation for those options?

Is there any way to change the default line length for the od and hexdump commands? Can't see anything apropriate in the man pages.

In bash, the command hexdump -C /dev/urandom > hexdump.txt does not terminate. It keeps going indefinitely, even if the filesystem is full. read(0, "\326\210L0\rL.%."..., 4096) = -1 ENOSPC (No space left on device) read(0, "\336&v\266I\10\254\3551\225\370\"^g\224\10\5\17h\tNkA.(\374\302\333`K/\332"..., 4096) = 4096 write(1, " ad 7a 3f 0c f4 0e a0 b8 8d |."..., 4096) = -1 ENOSPC (No space left on device) write(1, "ab 1c f4 79 f1 49 20 0e a1 f3 7"..., 4096) = -1 ENOSPC (No space left on device) In the event that it does terminate (when the input is not infinite) it still reports a write error at the very end... but by that point it has consumed the input entirely, producing countless ENOSPC errors. Then I tested other commands. busybox hexdump has the same issue. od has the same issue. strings has the same issue... So this involves util-linux, coreutils, binutils, ...? I can work around the issue like hexdump -C /dev/urandom | cat > hexdump.txt this works since cat, dd, pv terminates on write error, which in turn kills the entire pipe. But it looks so weird. Is this a bug across the board or is there some standard that requires these utils must consume all inputs?

I wish to dump the raw content of a SD card into a file for inspection. Most parts of it are zeroes. Learnt from this SuperUser answer I could use pv to show the progress of od and hexdump. Both ETA are 1.5 hours. # pv /dev/sdd | od -x --endian=big > sdd_file ... ... ... [> ] ... ETA 1:34:42 and # pv /dev/sdd | hexdump -C > sdd_file ... ... ... [> ] ... ETA 1:35:01 However xxd would need 11 hours. # pv /dev/sdd | xxd -a -u > sdd_file ... ... ... [> ] ... ETA 10:48:53 I prefer xxd mostly because of the -revert possibility. But xxd would take way too long to process a disk. How to format hexdump (or od) to produce the same file format as xxd, so that the file is possible to be -reverted by xxd?

By looking at a particular line of a text file (say, the 1123th, see below), it seems that there is a non-breaking space, but I am not sure: $ cat myfile.csv | sed -n 1123p | cut -f2 Lisztes feher $ cat myfile.csv | sed -n 1123p | cut -f2 | od -An -c -b L i s z t e s 302 240 f e h e r \n 114 151 163 172 164 145 163 302 240 146 145 150 145 162 012 However, the ASCII code in octal indicates that a non-breaking space is 240. So what does the 302 correspond to? Is it something particular to this given file? I am asking the question in order to understand. I already know how to use sed to fix my problem, following this answer : $ cat myfile.csv | sed -n 1123p | cut -f2 | sed 's/\xC2\xA0/ /g' | od -An -c -b L i s z t e s f e h e r \n 114 151 163 172 164 145 163 040 146 145 150 145 162 012 For information, the original file is in the .xlsx (Excel ) format. As my computer runs Xubuntu , I opened it with LibreOffice Calc (v5.1). Then, I saved it as "Text CSV" with "Character set = Unicode (UTF-8)" and tab as field separator: $ file myfile.csv myfile.csv: UTF-8 Unicode text

On my Termux, for example, the following can be obtained: $ od -A n -t x1 /dev/urandom | head -n 2 e3 5d bf 57 fb 8b 63 06 4a 18 fe 28 73 8f 3e c0 9f 08 6b d4 2d 38 2c 68 3c 51 83 1e 71 7b 57 2b As you can see the values are separated with space character. SUSv2 says: > The input data is manipulated in blocks, …. Each input block will be written as transformed by each output type, one per written line, in the order that the output types were specified. If the input block size is larger than the number of bytes transformed by the output type, … the output from each of the transformations will be separated by one or more blank characters. I omitted some unnecesary parts by replacing with '…' on the quotation above. 2004 and 2018 editions of POSIX say same things as above. Does the specification mean that it is possible to separate each byte, word, or whatever with tabs, '\f', '\r' and any other [:blank:] (in BRE) things instead of spaces and LFs? PS. Actually I was thinking of the most efficient and fastest way to make each byte into each line, in range of POSIXism. At first I thought od -A n -t x1 -v | tr ABCDEF abcdef | tr -Cd abcdef0123456789\\n | fold -w 2 | grep . or somethig similar would be better. Then I found out the POSIX specification saying something questionable, as above. Also how about decimals: od -A n -t u1 -v | tr -Cs 0123456789- '[\n*]' | grep . is one way, but what about not using tr -C...? Would it make it faster? That is the purpose.

I converted a simple binary file into a text file with: od –t x1 Check.tar | cut –c8- > Check.txt Which gives a content similar to: 64 65 76 2f 6e 75 6c 6c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [...] What is the opposite way -- to convert Check.txt to Check.tar as the original file?

I think I may be overlooking a relatively fundamental point regarding shell. Output from the **ls** command by default separates output with newlines, but the shell displays the output on a single line. Can anyone explain this to me? I had always presumed that the output was simply separated by spaces, but now that I see the output separated by newlines, I would expect the output to be displaying on separate lines. Example: cpoweradm@debian:~/lpi103-4$ ls text* text1 text2 text3 **od** shows that the output is separated by newlines: cpoweradm@debian:~/lpi103-4$ ls text* | od -c 0000000 t e x t 1 \n t e x t 2 \n t e x t 0000020 3 \n 0000022 If newlines are present, then why doesn't the output display as: text1 text2 text3

Hi now I write bytes data (for eg, **\x00\x11\x22**) from my PC to serial port of my device running unix at the ttyS1 port. I am able to print the data using either cat /dev/ttyS1 od -x < /dev/ttyS1 both works, but with cat I get "▒▒" printed. With od, i see some data bytes: 0000000 00fe 0000001 Which is not what i sent (001122Hex). How can I get the correct hex display? **EDIT**: tty permission set: stty -F /dev/ttyS1 speed 115200 cs8 -cstopb -parenb -echo time 3 min 0 **EDIT2**: Something weird is happening I am not sure why. I tried to send different data: "1049" which my program then sends as "\x10\x49". od returns: 0000000 4910 0000002 Seems it reversed the bytes. But what I don't get now is if I have repeated number like "\x11\x49" at once the data becomes corrupted. Seems like all repeated value like x11, x00, x22, are translated wrongly for some reason. And, any value over 8 also wrongly translated. Any idea why? Use either hexdump or od give same result.

od (octal dump) command is implemented in Unix since Version 1. However, I couldn't find a reverse command in the [Version 6 Unix manual](https://ia800600.us.archive.org/19/items/v6-manual/v6-manual.pdf) (1975). Modern ways of reversing od with either xxd or sed do not apply to Unix V6, since sed and awk appeared only in Version 7 (while uudecode, xxd and base64 are not available neither). The questions are: - How did people in 1975 convert octal or hex listings into binary files? - How can I do this in a PDP-11 emulator that only allows me to paste text into terminal from clipboard? (In other words, is it necessary to write my own program for that?) Here is a sample hex dump of a binary file by od that I'd like to convert back into binary: # od -h /bin/sum 0000000 0107 00ba 0000 0204 0000 0000 0000 0001 0000020 1583 0bd6 0ac3 0601 8901 0a37 00ae 15b7 0000040 0002 8905 0000 0000 8609 15c0 0001 8904 0000060 0026 0005 01ef 706f 6472 000a 1001 0a05 0000100 1040 8903 00be 0200 870b 0bc0 030e 0ab7 0000120 007a 15c2 00be 9484 6105 0b45 7e04 01f0 0000140 15c0 0001 8904 0080 0002 09f7 0026 15c0 0000160 0001 8904 0083 0001 1dc5 0050 09f7 0014 0000200 15c0 0001 8904 0082 0001 1040 8906 01c2 0000220 203f 200a 1026 1066 1141 09f7 0006 1581 0000240 1580 0087 0a00 7217 000a 1066 1001 0302 0000260 09f7 fff0 15b7 0012 65f7 0030 000c 15c0 0000300 0001 8904 00ba 0001 0087 0000312

I am running the od command as od -b myfile to convert a file I have into image pixels. I need to see all the values but because they are too many the command prints the following: 0000000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 * 1130000 Is there any way to get all my values instead of just the first and the last?

I would like to understand the content of the following file system /var/run/utmp. When I use the command od to open it I see the following: [john@iceman ~]$ od -c /var/run/utmp 0000000 002 \0 \0 \0 \0 \0 \0 \0 ~ \0 \0 \0 \0 \0 \0 \0 0000020 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000040 \0 \0 \0 \0 \0 \0 \0 \0 ~ ~ \0 \0 r e b o 0000060 o t \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000100 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 3 . 1 0 0000120 . 0 - 6 9 3 . 1 1 . 1 . e l 7 . 0000140 x 8 6 _ 6 4 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000160 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 What these numbers/characters means? In which coding system it was written? and how can it be translated into a meaningful text?

I have a bash function using **od** command. Now I'm trying to run in on OpenWRT and see that in has not od. Also can't find it using install from opkg, because I can't find it. Is there a possibility to install it manually? I also know about **sed** but are not that familiar with it. Is it possible to do this exact task: function format { #1=data type (like u1) 2=How much bytes 3=byte starting position in file 4=file od -An -t $1 -N $2 -j $3 $4 }

We have a file named as abc.txt and its a empty file. Due to some junk or control M characters, the file size is populated as 5 byte file. In order to have clean file we are using dos2unix command to remove the unknown character's. After using dso2unix command We can see the file size as 1 byte as it only contains a new line character .Can i know how to remove newline character if it is the only character in the entire file ? **Work Around :** cat abc.txt cat -v abc.txt M-oM-;M-?^M ll abc.txt -rw-r--r-- 1 ORAPRD ADMIN 5 Jan 25 07:08 abc.txt dos2unix abc.txt dos2unix: converting file abc.txt to Unix format ... ll abc.txt -rw-r--r-- 1 shpprd ADMIN 1 Jan 25 07:09 abc.txt cat -v abc.txt od -c abc.txt 0000000 \n 0000001 Does any one have solution for this? Thank you.

Is it correct that od can't show binary number? I can't find an argument to provided to its -t option for showing binary number. I feel it is natural to expect od to show binary number, or do I miss something? (xxd -b can) Thanks.

I have a file which is Non-ISO Extended ASCII type. I can't see its content just by opening it normally via cat or vim. However, I'm able to see its content in readable form with this command... od -w128 file.txt Does anyone know how this file was created in the first place ?

I am making my own od utility based on the Single UNIX Specification and I am confused on how the representation of floats is handled e.g. od -t f. I have a perfectly functioning utility otherwise that is able to handle every other portion of the specification also this is not a programming question but a question on the meaning of the output when dumping as a float. For example if I execute the following program supplying to stdin the ASCII characters **A\n** i get the following: $ od -A n -t fD - 1.297e-320 If I just supply **A** $ od -A n -t fD - 3.2e-322 I know the value for the A and newline characters are 65 and 10 respectively so I have no clue what these exponentially small numbers mean in the context. The specification does not give much coverage to floats so I would appreciate any information on this point.

I have output from an od command (without access to the original file). Is it possible for me to get the binary data and insert it into another file with a programming language, like python? Here is the command and output: od -c IUSZ43_KWBC_081935_59763868.bufr 0000000 001 \r \r \n 8 6 8 \r \r \n I U S Z 4 0000020 3 K W B C 0 8 1 9 3 5 \r \r \n 0000040 B U F R \0 \0 366 003 \0 \0 022 \0 \0 \b \0 \0 0000060 002 \0 \r \0 022 \b \b \f \0 \0 \0 \0 & \0 \0 001 0000100 200 301 001 002 \v 002 \f 301 \v 301 \f 301 030 A \r 303 I have for edit control over the new file that this data will be appended to. But to reiterate I do not have access to the IUSZ43_KWBC_081935_59763868.bufr file.