0

This question already has an answer here:

We all know "a.out" is file-format used to denote object code(binary) and is abbreviated form of assembler output, then cat a.out should also give us binary but why this doesn't happens?

I am expecting the output to be pure binary, by which I mean only 1's and 0's.

marked as duplicate by slm Jul 20 '18 at 16:48

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • What created the a.out file? Where did you find it? What are it's contents? More information please. – Jesse_b Jul 20 '18 at 13:35
  • 1
    "Binary" just means "non-text". When you run cat on it, the terminal tries to display it as text. That is, probably in groups of eight bits at a time, interpreted as characters. – Kusalananda Jul 20 '18 at 15:01
  • 2
    See: Mystery of binary files – Renan Jul 20 '18 at 15:31
  • 1
    @daya - right, that's the point of why we link questions to duplicates. The dup stays on the site and is another avenue to drive users to the correct answer(s). There is nothing inherently bad w/ a dup, it's actually a good thing, since many Q's can and will have the same or a few answers. – slm Jul 21 '18 at 5:12
  • 1
    @slm Actually, Mystery of binary files have more informative answers :) – daya Jul 21 '18 at 5:32
3

Compiled code is just a (usally rather long) sequence of bytes. If you cat such a file, the terminal tries to display the characters with the same byte value within ASCII/UTF8/UTF16. This fails for most byte combinations, so the result of cat a.out looks like gibberish.

To see the binary values in hexadecimal use

$ od -x a.out
0000000      facf    feed    0007    0100    0003    8000    0002    0000
0000020      000f    0000    04b0    0000    0085    0020    0000    0000
0000040      0019    0000    0048    0000    5f5f    4150    4547    455a
0000060      4f52    0000    0000    0000    0000    0000    0000    0000
0000100      0000    0000    0001    0000    0000    0000    0000    0000
...

or, if you have it on your system,

$ hexdump -C a.out
00000000  cf fa ed fe 07 00 00 01  03 00 00 80 02 00 00 00  |................|
00000010  0f 00 00 00 b0 04 00 00  85 00 20 00 00 00 00 00  |.......... .....|
00000020  19 00 00 00 48 00 00 00  5f 5f 50 41 47 45 5a 45  |....H...__PAGEZE|
00000030  52 4f 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |RO..............|
00000040  00 00 00 00 01 00 00 00  00 00 00 00 00 00 00 00  |................|
...
00000f90  00 00 00 41 53 ff 25 65  00 00 00 90 68 00 00 00  |...AS.%e....h...|
00000fa0  00 e9 e6 ff ff ff 48 65  6c 6c 6f 2c 20 57 6f 72  |......Hello, Wor|
00000fb0  6c 64 21 0a 00 00 00 00  01 00 00 00 1c 00 00 00  |ld!.............|
00000fc0  00 00 00 00 1c 00 00 00  00 00 00 00 1c 00 00 00  |................|
...
  • But I still can't understand what does facf, feed, 0003 or 0085 etc. in od -x a.out I mean the output should be pure binary isn't? – daya Jul 20 '18 at 13:53
  • @daya These are the hexadecimal values of the compiled code. What do you mean by "pure binary"? – nohillside Jul 20 '18 at 13:58
  • By "pure binary" I meant only 1's and 0's. – daya Jul 20 '18 at 14:12
  • hexadecimal is a shortcut to display binary, for instance facf is 1111101011001111 if you prefer, but hexadecimal is shorter. – Archemar Jul 20 '18 at 14:16
  • 2
    ... and each 1 in that last comment is the ASCII code for the letter 1, which in turn is a 8-bit number. I think the point here is that the user can't see why the "binary" is not stored as series of text digits. – Kusalananda Jul 20 '18 at 15:05
2

All files are only a sequence of number. All files are "pure binary" as you define it.

The meaning of the numbers in a file depends on how you choose to translate it.

Let's do an example: the file helloworld.c is a simple C program. Not an executable but a source code file.

The od -t c program translate the numbers in "characters" using a convention called "ASCII":

~ $ od -t c helloworld.c
0000000   #   i   n   c   l   u   d   e       <   s   t   d   i   o   .
0000020   h   >  \n  \n   i   n   t       m   a   i   n   (   i   n   t
0000040       a   r   g   c   ,       c   h   a   r       *   *   a   r
0000060   g   v   )       {  \n  \t   p   r   i   n   t   f   (   "   h
0000100   e   l   l   o       w   o   r   l   d   "   )   ;  \n   }  \n
0000120

The od -t x1z program translate the numbers of the file as exadecimal numbers and as characters (in the last column):

~ $ od -t x1z  helloworld.c
0000000 23 69 6e 63 6c 75 64 65 20 3c 73 74 64 69 6f 2e  >#include <stdio.<
0000020 68 3e 0a 0a 69 6e 74 20 6d 61 69 6e 28 69 6e 74  >h>..int main(int<
0000040 20 61 72 67 63 2c 20 63 68 61 72 20 2a 2a 61 72  > argc, char **ar<
0000060 67 76 29 20 7b 0a 09 70 72 69 6e 74 66 28 22 68  >gv) {..printf("h<
0000100 65 6c 6c 6f 20 77 6f 72 6c 64 22 29 3b 0a 7d 0a  >ello world");.}.<
0000120

The xdd -b program translate the numbers of the file as binary numbers and as characters (in the last column):

~ $ xxd -b helloworld.c
00000000: 00100011 01101001 01101110 01100011 01101100 01110101  #inclu
00000006: 01100100 01100101 00100000 00111100 01110011 01110100  de <st
0000000c: 01100100 01101001 01101111 00101110 01101000 00111110  dio.h>
00000012: 00001010 00001010 01101001 01101110 01110100 00100000  ..int
00000018: 01101101 01100001 01101001 01101110 00101000 01101001  main(i
0000001e: 01101110 01110100 00100000 01100001 01110010 01100111  nt arg
00000024: 01100011 00101100 00100000 01100011 01101000 01100001  c, cha
0000002a: 01110010 00100000 00101010 00101010 01100001 01110010  r **ar
00000030: 01100111 01110110 00101001 00100000 01111011 00001010  gv) {.
00000036: 00001001 01110000 01110010 01101001 01101110 01110100  .print
0000003c: 01100110 00101000 00100010 01101000 01100101 01101100  f("hel
00000042: 01101100 01101111 00100000 01110111 01101111 01110010  lo wor
00000048: 01101100 01100100 00100010 00101001 00111011 00001010  ld");.
0000004e: 01111101 00001010                                      }.

The first number of the file can be shown as 35 (in decimal), as 00100011 (in binary), as "#" (in UTF-8). It depends on how do you choose to translate it.

  • cat doesn't translate anything. It copies the data as-is. It's the terminal that interprets the data as characters to display (or escape codes to move the cursor etc.). In the same way as when the shell outputs the bytes that correspond to your prompt, or ls outputs the bytes that correspond to some filenames. – ilkkachu Jul 20 '18 at 15:23
  • @ilkkachu Yes, you are right. – andcoz Jul 20 '18 at 15:26
  • Now, it's better. It is still inaccurate on many other levels but ... – andcoz Jul 20 '18 at 15:33

Not the answer you're looking for? Browse other questions tagged or ask your own question.