Ok, you are a switcher. You used to be a Windows user, but you've
seen the light and moved to Linux or Mac OS X or BSD or.. well,
whatever it is, you are in *x land, baby and we're glad you are here.
But just like moving into a new town, you need to learn your way around,
find out where things are and how they work.. you need to get yourself
oriented, right?

OK, first things first. There is a book. As I don't know what
you might have switched to or from, I can't be specific here, but
I guarantee you there is a book. I've reviewed a lot (I mean a LOT)
if *xish books at "/Books" here, so you might
want to poke through some of those, but if you don't find it, that
doesn't mean it doesn't exist - I just haven't read it. It is out there,
and you probably should read it.

But having done that, what next? You are competent now, you know
how the Window system works, you know where to find the admin tools,
but how does this puppy really work? Here are a few things I do:

Hunt for shell scripts

A surprising amount of *xish stuff is written as simple shell
scripts. I found one hundred in /usr/bin on my Mac OS X box, and
more than that in /usr/bin on my Linux server. Here's the thing
about those scripts: they can teach you stuff. Stuff about programming
shell scripts, definitely, but also stuff about how the system works
in general. Here's a little script that will find those scripts for you:

#!/bin/bash
IFS=":";
set $PATH
for i in $*
do
file $i/* | grep "Bourne shell"
done

Note: your "file" may not return "Bourne shell script text executable"
as both my Linux and Mac systems do. That's OK, just figure out how it
does identify scripts and grep for that instead.

I am curiously tabbing

And so should you. If you have bash and are using it as your
default shell, try this: type "t" (or any other letter) and hit TAB
twice. Ooops, what was that? Well, just a look at every command in
your PATH that begins with "t", that's all. Do you know what each of
them does? No? Then let's try to find out - for example, on Linux
or Mac, you'll find "tack". What is it? Well, "man tack" will
tell you that it's a "Terminfo Action Checker" and if at this point you
know nothing about "terminfo", that might prompt you to try
"man terminfo" or "pinfo terminfo" (and you might read Termcap and Terminfo here also). There's
no telling where poking around with TAB might lead you.

Strings and stuff

Sometimes "man" and "pinfo" will let you down. "We regret to inform
you that we have no information available for your inquiry" - well,
no, they aren't quite that polite, but they aren't going to help you.
Maybe oversight, maybe it's just not something you need to know about..
but hey, maybe it's a shell script! Often undocumented little thingamabobbies
are shell scripts, and if so, looking at it in an editor might help
give you a clue. If not, don't panic. Sometimes it's a link to
some other command. Use "ls -li" to find out how many links it has -
if it's more than one, go find its clones with "find". Let's say we find
something with two links and then "ls -li" tells us that its inum is 56789.
If its twin is right here in this directory, you'll find it almost
instantly with "find . -inum 56789". If not, you'll need to
expand farther, searching the current filesystem for that same number.

But maybe it isn't a link and isn't a shell script. Well, sometimes
Google can help figure out what it might be, but so can some tools
right on your machine : doing "strings mysteryfile" can sometimes give
you a clue (hint: "strings `which mysteryfile`" is quick if you aren't
already sitting where this lives). Often just a simple "mysteryfile -?"
will spit out a help or usage message. But maybe it's very stubborn?

Well, if this is a Linux system that uses RPM, there is a secret weapon you can use:

rpm -q --whatprovides `which mysteryfile`" 

Note that this little line is also very useful when you know something needs updating - it tells you which RPM you need to go find.

There's something similar for apt based systems:

dpkg -S `which mysteryfile`

Source it

Not always possible, of course, but you MIGHT have the source for
this little bugger. Try a "find / -name mysteryfile.c" if Google
hasn't been helpful. This has lttle to do with learning *x, but
I've gotten lucky with mystery applications more than once - the
long absent original programmer had been kind enough to leave source that
I could find.

Step it

If all else fails, try running it in a debugger. You'll need
to know a bit about system calls and all, and when I earlier suggested
running "mysterfile -?" you surely wouldn't want to do that as root?
Well, you wouldn't want to do this as root either - just in case.

Give up?

No, not quite yet. There's two more possibilities. The first
is trying "ldd" to see if the library dependencies might give us
a hint. If not, my final clutch is to see if this file is referenced
in any other binary or script.. that may involve a bit of work with
"strings" and "grep", but once in a great while I have found
good clues from this.

And finally: break it

If all other wells have turned up dry, I have one more trick up
my sleeve: rename the darn thing and see what breaks. That's pretty
drastic, but if you've been through everything else, it's
unlikely that this is system critical. Renaming it will obviously
break something, somewhere, although it may take you quite a while
to find out what. If it really is important, you'll find out
pretty quickly - maybe from a phone call if other folks
use this system too, maybe from a message in a log file.. but you'll find it.

And then you'll know what it does, right? Isn't learning fun?

| << Home | 9:10 PM | Technorati | Ping