If you try to read on your screen with, say, , you'll see a lot of non-printable characters. Buried in there somewhere though are words and strings of characters that might make some sense. For example, if the code is copyrighted, you can usually find that information in the binary. The pathnames of special files that the program reads will probably show up. If you're trying to figure out which program printed an error message, use strings on the binaries and look for the error. Some versions of strings do a better job of getting just the useful information; others may write a lot of junk, too. But what the heck - pipe the output to or , redirect it to a file - ignore the stuff you don't want.
Here's a (shortened) example on SunOS:
strings /bin/write@(#)write.c 1.10 88/05/10 SMI Usage: write user [ttyname] write: Can't find your tty Message from %s@%s on %s at %d:%02d ... Write failed (%s logged out?) ((((( DDDDDDDDDD
The first line comes from
you can see the version number, the date the code was last modified or
released, and so on.
%02d are special places that the
printf(3) function will replace with values like the username,
hostname, hour, and minute.
By default, strings doesn't search all of a binary file:
it only reads the initialized and loaded sections.
- (dash) option tells strings to search all of the file.
Another useful option is
n, where n is the
minimum-length string to print.
Setting a higher limit will cut the "noise," but you might also lose
what you're looking for.
n command does a similar thing:
finds all null-terminated strings that are at least n characters