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) of *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 shell 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`
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.
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 "mysteryfile -?" you surely wouldn't want to do that as root? Well, you wouldn't want to do this as root either - just in case.
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?
Got something to add? Send me email.
(OLDER) <- More Stuff -> (NEWER) (NEWEST)
Printer Friendly Version
Increase ad revenue 50-250% with Ezoic