Tag Info

Hot answers tagged

25

When you pipe the output, ls acts differently. This fact is hidden away in the info documentation: If standard output is a terminal, the output is in columns (sorted vertically) and control characters are output as question marks; otherwise, the output is listed one per line and control characters are output as-is. To prove it, try running ls and ...


10

hd is a synonym for hexdump -C on FreeBSD and on some Linux distributions. hexdump is from the BSD days; od is from the dawn of time. Only od is standardized by POSIX. The Single UNIX rationale discusses why od was chosen in preference to hd or xd. These commands do very similar things: display a textual representation of a binary file, using octal, decimal ...


8

For hysterical historical reasons, od prints two-byte words¹ by default. The number 020061 (octal) corresponds to the two-byte sequence 1␣ (␣ is a space character). Why? It's clearer if you use hexadecimal: 0o20061 = 0x2031, and ␣ is 0x20 (32) in ASCII and 1 is 0x31 (49). Notice that the lower-order bits (0x31) correspond to the first character and the ...


5

POSIX: printf a | od -A n -t d1 Perl: perl -e 'print ord($ARGV[0])' a Perl, coping with UTF-8 if in a UTF-8 locale: perl -C255 -e 'print ord($ARGV[0])' œ


5

Linux doesn't let you do a plain read(dir_name, buffer, sizeof(buffer) - it always returns -1 and puts EISDIR in errno. This is probably rational, as not all filesystems have directories as files. The commonly-used reiserfs does not, for example. You can use the open() system call from a C program to get a file descriptor of a directory, but things like ...


5

Those numbers are octal (base 8) It'll only backslash something that has a symbolic name (\n, \b, \t, etc.) (I prefer hd -- hexdump -C -- myself.)


4

Assuming you mean the byte offset, from man od -A, --address-radix=RADIX output format for file offsets. RADIX is one of [doxn], for Decimal, Octal, Hex or None so for example od -An file


4

You're running od on a little-endian machine. >>> 0x1f1b 7963


3

Interesting question. After browsing the man page, I found that -o prints octal output (od == octal dump), the c you appended only prints the associated characters as well. You get the same numbers with -o alone. Looking at the output it appears that od is reading data two bytes at a time. Take the first two characters for instance: CHAR - OCTAL - BINARY 1 ...


3

One of the first things I had to memorise for computer science was Data + Interpretation = Useful Information. A corollary of this is that if you're missing Data or Interpretation, you have nothing. The data itself can't tell you how to interpret it. (you can have metadata which tells you this, but then you need to know how to interpret the metadata too) ...


2

There are lots of ways of storing numbers - ascii (which can have locale specific variants, such as using ',' to seperate fractional part OR as a thousands grouping), binary integer (variable number of bits)/float/double (all of which may vary depending on endian architecture and whether software producing the file formalises the representation), BCD ...


2

Your discovery highlights the primary reason why parsing the output of ls is always a bad idea. See Greg's wiki for a full explanation. Think of your problem in reverse. You noticed that ls sometimes does and sometimes doesn't print newlines between it's output. For use in scripts or when forced by the -1 flag, it does. One newline at the end of each file. ...


2

Maybe: #!/bin/bash echo -n "Enter a letter:" read A echo ${A}|od -t d1|awk '{printf "%s",$2}';echo Cheers


2

"Named characters" means the output will print the name of a character rather than its numerical ASCII value. For printable characters, the name used is the actual character and for non-printable the names are things like nl for newlines and sp for spaces. The high-order bit is the bit with the highest value. For single-byte ASCII characters, this bit ...


2

od -An -vtx1 Check.tar > Check.txt You need -v or od will condense sequences of identical bytes. For the reverse: LC_ALL=C tr -cd 0-9a-fA-F < Check.txt | xxd -r -p > Check.tar Or: perl -ape '$_=pack "(H2)*", @F' Check.txt > Check.tar If your purpose is to transfer files over a channel that only supports ASCII text, then there are ...


1

Answering the X part of this XY problem, I would recommend you investigate the reason your binary file transfers don't transfer properly. If it turns out the reason is because you don't have an 8-bit clean datapath you could then use existing tools that were created to handle this situation, such as base64 or even uuencode. Old but still very effective. ...


1

od doesn't show bytes by default, it shows words in octal. This may not quite be intuitive, but don't forget od is a very old command :-) I'll use a somewhat simpler example than you did: $ echo -en '\01\02' | od 0000000 001001 0000002 As Intel uses a little-endian architecture, the bytes \01\02 are interpreted as 00000010 00000001 in binary. As octal ...


1

od has the --width=N argument, which you can use to choose how many bytes per line, perhaps that's what you're looking for? hexdump has a -e FORMATSTRING which has promise, but I've never played too much with it.


1

A od-less solution, just bash, and just lowercase, so far. z is the character searched for, here s as search. i=97 because ascii(a)=97. The rest is obvious. z=s i=97 for c in {a..z} do [ "$c" = "$z" ] && echo $i && break || ((i+=1)) done You may put it into a single line of course. Here are some semmicolons: ;;;;; (should be enough)



Only top voted, non community-wiki answers of a minimum length are eligible