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:
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.
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.
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.
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?
Have you tried Searching this site?
Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates
This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.
Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.
Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.
We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.
Click here to add your comments
Don't miss responses! Subscribe to Comments by RSS or by Email
Click here to add your comments
If you want a picture to show with your comment, go get a Gravatar