"Linux Gazette...making Linux just a little less scary!
"
"Linux Gazette...making Linux just a little less scary!
"
You've made it to the weekend and things have finally slowed down. You crawl outa bed, bag the shave 'n shower 'cause it's Saturday, grab that much needed cup of caffeine (your favorite alkaloid), and shuffle down the hall to the den. It's time to fire up the Linux box, break out the trusty 'ol Snap-On's, pop the hood, jack 'er up, and do a bit of overhauling!
Time to become the Linux Weekend Mechanic!
And
Just What Is the Linux Weekend Mechanic...?Glad you asked... :-)
After a very busy year creating, writing, editing, proofing, and producing the first eight issues of the Linux Gazette I'm happy to say that it's been turned over to the kind folks at the Linux Journal who will be continuing its production. My special thanks to Phil Hughes, the producer of the Linux Journal who first broached the subject of taking over the Gazette when the time commitment was getting out of hand, AND to Marjorie Richardson, the new editor of the Gazette whose wit and wisdom should ensure that the LG will continue to flourish.
And now that someone else is doing the day to day management of the Gazette I'm back to reading, writing, and tinkering -- and this is what the Weekend Mechanic is all about.
I'd like to try to put together a monthly column for the Gazette that deals with customizing and running Linux on a personal, stand-alone (i.e., not directly networked) PC. The scope of topics may include things such as:
Basically, it covers the topics that I've found interesting using Linux on my PC at home -- I've got a shiny new Cyrix P-166+ machine as of August of this year and have 'Net access via a dial-up PPP connection. So, since I'm writing from my own experiences, you can anticipate the types of topics I'd likely be covering. I should add one important proviso: Keep in mind that many of the suggestions and ideas are NOT useful or recommended in a networked or multi-user setting in which security is an issue!!
Let me say this another way:
Caveat Emptor!
Because I have a stand alone box and a wife who absolutely hates using computers I'm the only one that has physical access to my machine. For this reason, security is not something that I've had to deal with. However, at MTSU, where I'm currently in school, we use both HP-UX machines and a number of P-133 machines running Red Hat 3.0.3 Linux with the 2.0 kernel upgrade. Security on these Linux boxes has been a VERY REAL issue of late -- if you're running Linux and someone else has potential access to your machine you'd be well advised to think twice before trying everything I might suggest. That's not to put a damper on anyone's enthusiasm, but having one's system hacked is a serious bummer.
And now that that's been said, I really do hope that the information here will be useful or helpful. The more I use Linux the more I'm amazed at its depth and breadth and the range of tools and programs that are available. It is seriously fun!
For this reason, I've decided to use the "Weekend Mechanic" motif. Thing is, if you're running Linux you've undoubtedly discovered that it takes more time to set up, configure, and fine-tune than most shrink-wrapped OS's. It's a "high needs" OS. Now, you could use one of those fancy-shmancy off-the-shelf Brand X OS's, but the question you have to ask yourself is...
Do you really want to be see hanging around an OS that looks like it comes with training wheels...?!!
I don't think so... ! ;-)
So, if you're one of those "I'd rather have a '68 Pontiac with a big block V8, Rochester QuadraJet, Dualies, and a box of Snap-On's than anything else" kind of folks...
Relax, you're in the right place. Welcome aboard :-)
The Talk About Town...For anyone who's been regularly reading the comp.os.linux.* hierarchy you'll realize that there's been a LOT happening recently within the Linux community. Here's just a smattering of some things that you might find interesting as well as other odds-n-ends.
Oh, and BTW...
Happy Halloween!
And now, back to the news...
Caldera to
release source code for DR DOS, CP/M, Novell DOS, and PalmDOSYup, you read that right!
Caldera has announced that it is in the process of a planned release of source code for DR DOS, CP/M, Novell DOS, and PalmDOS AND the beginning of a project which they are calling OpenDOS. The announcement stated a tentative date of the first quarter of 1997 for this to occur. Drop by and have a look. I think you'll find it interesting.
If you've got the hard drive space and want to do a bit of hacking away at something new, here's an interesting opportunity.
Did you know that
there's a "FreeDOS" Project underway...?Yup, there's a group working on a freely available version of a DOS-like OS. You can find out more on what they're doing, how to get a copy of the current version, and how to contribute to this effort by checking out the FreeDOS home page at sunsite.unc.edu/pub/micro/pc-stuff/freedos/freedos.html.
And speaking of new toys...
StarOffice and
Adobe beta software for Linux!StarOffice, a German software developer, has recently announced a freely available beta version of its StarOffice suite of productivity applications for the Linux OS. This is a seriously cool application suite that has a LOT of high end features. One caveat: you'll need a copy of the Motif libraries in order to run these applications. If you don't have motif, then you might want to try some gentle arm-twisting to see whether the folks at StarOffice would release a statically-linked version.
For those of you with Motif, you can get the installation "disk sets" at any sunsite mirror such as:
in their /pub/linux/apps/staroffice/ directory. Also, Adobe has just announced a beta version of their Adobe Acrobat 3.0 reader for the Linux OS. You can find out the particulars of how to obtain a copy at:
in their /acrobat/readstep.html page. I just got a copy of this and the installation was a breeze. At least on my system, load time was about what all motif-based apps tend to be (read: "somewhat slow") but performance thereafter was really quite good.
If you're interested in having a peek at a screen shot with one of the distributed pages, here's a look at it:
ADOBE Acrobat 3.0 screen dump (~40K) 810x630
Keep in mind that the official stance is that it is only supported under the Yggdrasil Fall '95 Linux distribution. However, under my 'ol Slackware '96 it runs just fine... Also, you'll notice the subtle subliminal message in the titlebar... :-)
And speaking of distributions...
Slackware '96 is
out and Red Hat Rembrandt is on its way!Now that the Linux kernel 2.0 is out and, for most folks, ELF is in, you'll find a number of much-awaited distributions with the 2.0 kernel and necessary development utilities. If you've been waiting to upgrade then now's the time!
There is a growing number of very good Linux distributions available, many of which now incorporate the recent kernel and development set upgrades. I've just installed Slackware '96 (AKA Slackware 3.1) which I received from the folks at
who are the official distributors of Slackware Linux. Since it was also my birthday recently my wife just got me a copy of the August, 1996 Linux Developer's Resource 6-CD Set from
Both of these are VERY nice sets that run in the $25 - $40 range and include a boatload of program sources from the usual linux FTP archive sites (sunsite.unc.edu, tsx-11.mit.edu, prep.ai.mit.edu, and so forth). Those of you who are on the monthly Mo' Linux mailing from
will have just gotten a copy of the Slackware '96 CD with the September edition of Mo' Linux. Pacific HiTech (PHT) has a VERY nice service which offers a monthly CD full of all kinds of goodies including the most recent kernel sources, new programs and updates from Sunsite's Incoming dir, the latest GNU stuff including GCC and its accessories, and so forth. They take special requests and have recently included things such as the huge Perl archives, Tcl/Tk archives, Python archives, the Java Development Kit (JDK), and so forth. Also, there are regular Red Hat RPM and SRPM updates each month for those running Red Hat systems.
And keep in mind that Red Hat's Rembrandt just hit beta release! This is their kernel 2.0 version and should be ready for regular release soon! You can get a copy of Rembrandt beta at the
as well as find all kinds of nifty info and links in their "Linux Info" page.
Since Christmas is just around the corner, I'm thinking about writing up a small "Wish List" of tools and toys that you might want to put on your Beloved's "Get For Me List". The small hoard of books and CD's on the bookshelf is growing -- next month I'd like to do a short piece on things that I've found useful. *YMMV.
*YMMV: "Your Mileage May Vary"
Here's the patch
for the sysklog bug in Slackware '96Those of you who've just installed Slackware 3.1 may have run into the same rather frustrating bug in the sysklog package that I did. After a recent installation, I found that syslogd would dump core after running pppd. About that time, postings to comp.os.linux.setup and misc suggested that this was a problem with the distribution and not with the hardware I was running.
So, after a request for help to Dr. Greg Wettstein, the maintainer of the sysklog package, I received the following patch from him that remedied the situation. For those of you needing this, you can get a copy of the message which Greg sent. Just load it and save it to disk as a text file. You'll also need a copy of the sysklog sources to recompile the program. Here's what you'll need:
Sysklog patch from G. Wettstein (~70K)
MANY thanks to Greg W. and the rest of the folks who've worked on this program.
I mentioned in the above announcement about StarOffice that you'll need a copy of the motif libraries to run this product (at least while it is distributed as shared-library executables). I really want to put in a good word for the folks at Red Hat Software Inc. and for their version of Red Hat Motif 2.0.
When I went to the Linux Expo '96 this past April, I had a seriously fun time meeting folks, chatting, perusing the various book and vendor tables, and sitting in on the various talks. If you missed it this past year and you can drive, fly, Amtrak, run, jog, walk, or crawl your way to Raleigh, North Carolina next Spring, then you won't want to miss it!! I don't know for sure if they're planning another Expo, but if so, you really don't want to miss it.
Anyway, while I was there I bought a copy of Red Hat Motif 2.0 and have been using it ever since. Now, I know that one of the FAQ's to the various comp.os.linux.**** groups is "HELP! Which Motif should I get?!!", or something to that effect. There usually ensues a modestly impassioned discussion about the merits and drawbacks of one's recent Motif purchase.
For the record, I'd like to say that I've been extraordinarily pleased with this product. It comes with a very complete User's Manual which covers installation and configuring the Motif Window Manager (mwm). The CD also contains the Motif libraries, development tools, and documentation in both *.tar.gz format and as RPM's.
Installation was a breeze using rpm version 2.0 and I've been compiling motif stuff without a hitch ever since. This includes programs such as mosaic, plan, llnlXFtp, llnlXDir, xtar, xmcalendar, xmdiary, XEmacs, GVim, and so forth. Compiling with the Motif libs has been completely transparent and using shared, pre-compiled binaries (such as StarOffice) has been flawless.
At a time when there has been a LOT of negative press towards a variety of individuals and institutions, let me offer a very heartfelt positive comment:
To the folks at Red Hat, thanks for a VERY nice product!
(FYI, I just got a copy of the most recent flyer from Surplus Direct, a distributor of, you guessed it..., surplus hardware and software. On page 17 of the flyer they offer the Red Hat's MOTIF for LINUX V2.0 CD for $99.99. Not a bad deal... :-) You can call them at 1-800-753-7877 U.S. or 541-387-6000 International. They even have a nifty web page which you can check out at http://www.surplusdirect.com)
More tar Tricks!OK, ready for a quiz...? Close your books, put away your notes, and answer the following question:
Without looking at the man page, (a) What does the following command do? and (b) Why on earth would you use it in the first place?
tar -tvzf file.tar.gz |tr -s ' ' |cut -d ' ' -f8 |less
Don't peek...!
(If this were a REAL web page, you'd click on a tiny icon of a music box and have it do RealAudio of that jingle from Jeopardy while an accompanied set of animated icons amuses you. But since I'm not that bright, you'll have to hum quietly to yourself and decide when you're tired of waiting... :-)
Figured it out?
If you guessed that it uses tar to do an archive listing on a tar'd and GNU gzip'd archive, then you'd be warm.
If you guessed that it uses tar to do an archive listing on a tar'd and GNU gzip'd archive and then piped the output to the GNU tr utility which would translate multiple instances of the space character into a single space character, then you'd be even warmer.
If you guessed that it uses tar to do an archive listing on a tar'd and GNU gzip'd archive and then piped the output to the GNU tr utility which would translate multiple instances of the space character into a single space character and then pipe that output to the GNU cut utility which would use that single space as a field delimiter and then print only the data in field 8, then you'd be hot.
And if you guessed that it uses tar to do an archive listing on a tar'd and GNU gzip'd archive and then piped the output to the GNU tr utility which would translate multiple instances of the space character into a single space character and then pipe that output to the GNU cut utility which would use that single space as a field delimiter and then print only the data in field 8 and then output all of that to the less pager so that you could view, search, edit, and optionally print the output, then you, my friend get to...
Go to the head of your class! :-)
Actually, I wouldn't have been able to guess this without peeking a bit, so don't feel bad if you didn't guess all of it correctly. But this answer only gives the answer to part (a). The real question you have to ask yourself is, "Why on earth would you do this in the first place?"
Good question.
I'll get to that in a moment, but first, let me ask a simple question: "How do you know what's actually inside a tar or tar+gzip archive without actually unarchiving it?" Now, you can always unarchive a tar.gz file and have a look at things but what if you really only wanted to see what was in it or just look at a single file in the archive. What do you do then?
The answer lies, at least in part, with our funky little command line above.
Let's see what we can do with this.
The first thing you've all probably realized is that tar has a bazillion or so command line arguments so you can do almost anything with it. As you've guessed, using the "-t" option displays a listing of the files in the archive. If the archive has been compressed, then using the "-z" option will automatically uncompress the archive.
So far, so good.
Thing is, what you want to do is actually look at one of the files in that archive. Say you wanted to have a peek at the README file that came with some program. Seems silly to have to unarchive an entire (potentially HUGE) file just to see one item. Those of you who've used tar for a while will realize where I'm going with this. You see, another one of tar's nifty little options is the "-O" (which can also be invoked as --to-stdout) which causes tar to send the output directly to standard output: generally, your computer terminal. This is what we need to use to get a look at some file in the archive -- we'll have tar send it to stdout so we can view it. That way, we won't need to unarchive the file.
The other piece of the puzzle involves how you get tar to unarchive a specific file within an archive. Again, you manual page readers will know that this is done by simply appending the filename(s) to the end of the argument. Now in case I'm starting to lose any of you, here's an example which should help clear things up.
Say that I have some archive such as the a2ps program (which does ASCII -> PostScript conversion, BTW). To get a listing of the files in the archive all I have to do is:
tar -tvzf a2ps-4.5.23.src.tar.gzand this gives me the following output:
drwxr-xr-x 11714/117 0 Sep 5 11:38 1996 a2ps-4.5.23/ -rw-r--r-- 11714/117 7721 Sep 5 11:38 1996 a2ps-4.5.23/INSTALL -rw-r--r-- 11714/117 2281 Sep 5 11:38 1996 a2ps-4.5.23/README -rw-r--r-- 11714/117 1429 Sep 5 11:38 1996 a2ps-4.5.23/TODO -rwxr-xr-x 11714/117 4773 Sep 5 11:38 1996 a2ps-4.5.23/install-sh -rw-r----- 11714/117 3576 Sep 5 11:38 1996 a2ps-4.5.23/Makefile.in -rw-r--r-- 11714/117 907 Sep 5 11:38 1996 a2ps-4.5.23/config.h.in -rwxr-xr-x 11714/117 47767 Sep 5 11:38 1996 a2ps-4.5.23/configure -rw-r----- 11714/117 1415 Sep 5 11:38 1996 a2ps-4.5.23/configure.in -rw-r--r-- 11714/117 81240 Sep 5 11:38 1996 a2ps-4.5.23/a2ps.c -rw-r----- 11714/117 70081 Sep 5 11:38 1996 a2ps-4.5.23/a2ps.h -rw-r--r-- 11714/117 15348 Sep 5 11:38 1996 a2ps-4.5.23/afm.h -rw-r--r-- 11714/117 10482 Sep 5 11:38 1996 a2ps-4.5.23/a2ps.manSo now, let's say that I want to have a look at what's in the README or the INSTALL file; well, now that you know that you send the output of tar to stdout you know you're golden! All you'd need to do is something like:
tar -xvzOf a2ps-4.5.23.src.tar.gz a2ps-4.5.23/READMEAnd, voila!, there's your file. The astute will immediately comment that piping that output to a pager such as more or less makes a lot more sense because now you can actually read more than just the last screen full of text.
Note, too, that the basic command line was (in pseudocode):
tar -options archive.tar.gz path/fileToViewNotice that you have to include the "a2ps-4.5.23/" portion and NOT just the name of the file.
So, now we're getting somewhere!
You can use the tar -tvzf FILENAME.tar.gz command line to get a directory listing of a tar archive and then use something like:
tar -xvzOf a2ps-4.5.23.src.tar.gz a2ps-4.5.23/README |lessto actually view the file -- the tar file is intact, nothing is unarchived to disk, and you fingers never leave your hand!
And now, let's pick up on our original question once again. Here's where that funky little command line becomes useful to use once again.
Those of you who've done a bit of shell programming know that, fundamentally, every programmer is lazy at heart. That is to say, shell scripts are a VERY convenient way of saving yourself the bother of typing the same commands over and over again -- and this is one of those places where this is handy.
Now that you know how to view a file from within a tar file without ever unarchiving the entire file, wouldn't it be handy to set up a shell script to do just that...?
You know I wouldn't have asked this if I didn't already have an answer in mind... eh?
Well, this is one of those things that I've started toying around with in the past couple days and while I haven't gotten anything written yet, that nifty little tar command at the top is part of the solution. You see, it would be quite handy to be able to do a listing of a tar archive, select one or more of the files, and then view them. The thing is, as I mentioned before, you have to give tar the full name of the file you wish to view -- including any path information. That is, if you'd tried to do:
tar -xvzOf a2ps-4.5.23.src.tar.gz README |lessyou'd have gotten an error message because there's no README file in the archive -- there is the file a2ps-4.5.23/README. See the difference? You have to have the a2ps-4.5.23/ prefix for tar to work correctly.
So, can you think of a way to take the output of tar -- the file listing -- and generate a listing of just the filenames which you can pass back to tar. Again, remember that it has to include the entire path+name but cannot be the entire line, such as:
-rw-r--r-- 11714/117 2281 Sep 5 11:38 1996 a2ps-4.5.23/READMESomehow, we've got to strip away all the leading stuff and get only to the a2ps-4.5.23/README entry. So let's cut to the chase.
One way to do this is using the method I mentioned above: using tar with the "-t" option displays a file listing. Next, you can use cut to access a single a column of data because, as you've all noticed, there are 8 fields of information in the above listing:
PERMISSIONS GROUP/USER SIZE MONTH DAY HR:MIN YEAR PATH/FILENAMENow, you'll also notice that these are separated by a space and so you should be able to use this as a field separator. But if you try something like:
tar -tvzf a2ps-4.5.23.src.tar.gz |cut -d ' ' -f8what you end up with is:
7721 2281 1429 4773 3576 Sep 1415 Sep Sep Sep SepSo what went wrong!?
Well, we used a space character as the field delimiter which was the correct thing to do. But have a look at the actual file listing. Notice that there is a single space between most, but not all, of the fields. Between the group/user field and the size field there is a variable number of spaces and there appears to be two spaces between SEP and 5. So, cut dutifully used a single space character as the field separator, but the result wasn't' what we expected.
Hmmm... now what...?
Well, there's another little mentioned but VERY useful utility called tr. It's a seriously handy little item that does, among other things, character translation. In this case, we can use it to truncate a series of one or more spaces into a single space (and THEN, cut should work correctly!).
Now, is the light dawning? :-)
We use tar to get the file listing, tr to truncate all the extraneous spaces into a single space character, and then pipe the whole thing through cut to get just the fields that we want. Doing this on the a2ps file, we get:
a2ps-4.5.23/ a2ps-4.5.23/INSTALL a2ps-4.5.23/README a2ps-4.5.23/TODO a2ps-4.5.23/install-sh a2ps-4.5.23/Makefile.in a2ps-4.5.23/config.h.in a2ps-4.5.23/configure a2ps-4.5.23/configure.in a2ps-4.5.23/a2ps.c a2ps-4.5.23/a2ps.h a2ps-4.5.23/afm.h a2ps-4.5.23/a2ps.man
Pretty slick, eh?
Now, we can pick any of these entries and if we pass them to tar using the "-O" option then the file gets printed to stdout. Pipe this output to less and we're golden!
A tar file viewer!
So why mention all of this?
Well, first, because I'm toying around with ideas for a shell script that will do just this -- write a small program that will let me view individual files from a tar.gz archive. I've got a couple ideas floating around and may try using the dialog program for a console UI, or I might just go ahead and try this using tcl/tk.
Second, I do this to point out one of the beauties of using Linux (or any UNIX type OS) and that is the use of pipes to connect any number of the myriad of utilities together into a powerful command. Using four programs and a bunch of pipes, we've seen how we can easily ready any file within a tar archive without having to uncompress the entire thing.
That is seriously cool!
Anyway, I've just started playing with this. Let me quickly mention, for those of you who already know and are waving your cyberhands in the air, that there is a very easy way to manipulate tar.gz files already -- and it's with a program that MOST Linux distributions already install: Midnight Commander.
I cannot say enough good things about this program. I'm honestly not much of a file manager type user -- I really do prefer the command line for most file and directory operations. But, mc is different. I have absolutely fallen in love with this. It's very well designed, is quite mature, has a boatload of nifty features, AND it'll let you easily view and copy files from a tar.gz archive using its VFS (virtual file system).
I've been wanting to do a write up on MC now for, quite literally, months and just haven't had the time to write a decent article -- one that really does it justice. Anyway, for those of you who are interested, all you have to do to access a tar.gz file is fire up mc, select the tar.gz file and either double click on it (if you're running gpm and have mouse support) or hit RETURN and it'll automatically unarchive the file into a VFS from which you can browse the archive just as though it were installed on your harddrive.
The other application that'll let you do this is the xtar program -- a motif based app that I recently came across at the ftp.x.org archive. I honestly haven't seen this at sunsite or tsx-11 and I don't know that I've seen it any of the usual Linux distributions either. It's a VERY nice little app that let's you browse and view tar.gz archives.
Anyway, try out mc or xtar if you want tar.gz browsing right now. But, let's see if we can't figure out a way to do something like this using shell scripting or tcl/tk. I'll let the interested work on this and, if I have any successes myself, I'll write this up in next month's issue.
Til then, Happy Scripting!
Basic File InformationOK, quick question:
Can you name 5 tools or utilities which you can use to get information about a file?
I'm sure you can if you give it a bit of thought. You see, most of the time, if you've installed a system yourself then you have a pretty good idea about what's on it and (hopefully...) where things are. But what if you come across a cryptically named file (Hmmm... fancy that on a UNIX system... :-) in your /usr/bin directory and want to get a bit of information about it. Or, what if you know what it is that you're looking for, but just can't find it!
Ok, so let's talk about a couple tools you can work with to get basic file information.
The one's that I was thinking about included:
Now, there are others, I'm sure, but these five basic utilities (seven if you count similar ones) will go quite a ways towards helping you get a handle on what's on your system.
Anyone's who's used Linux for more than..., Hmmm... about a day or so, has run across ls which does a directory listing. And, if you've ventured a peek at its manual page, your first reaction may have been one of incredulity at the bewildering number of command line options. Fear not. You really only need a couple of these on a routine basis (these are your friends) and the rest of these let you do all kinds of groovy and interesting things when you have nothing else to do but play with your directory listings (these are you great Aunt Fanny's half-sister's double cousin, twice removed... you know they're around, you just have no earthly idea as to what they do).
So, you know that if you want to get basic information about a file, then the best place to start is with a directory listing. Using the "-l" option gives you a long listing which includes the file type (regular, directory, fifo, block, and so forth), number of hard links, user name, group name, size in bytes, timestamp (generally, the modification time), and the file name itself.
You also know, I'm sure, that adding the "-a" displays all files, including all the so-called dot-files which begin with a period (.) and which are normally not displayed in a directory listing.
Many Linux distributions also configure ls to use the "-F" option which print a suffix after each file to indicate what its basic type is:
So, just using humble 'ol ls can give you quite a bit of information about your files. A couple of the more useful things that you can do with ls include using the "-t" option which sorts the directory contents by time. This is very useful if you happen to be in a directory such as /usr/bin that has a LOT of files and you're looking for something which you've recently added but can't recall the name. Using "ls -lt" causes all the newest files to, as it were, rise to the top of the list. If, however, you want to list the latest files last, no problem, mon, just add the "-r" option to the soup and you'll get a reversed listing by time (i.e., "ls -ltr").
Yet another handy little option will let you find out when a file's status was last changed. The status includes things such as owner or group information or permissions. You can change these things without actually modifying the file itself. Generally, the time stamp indicates when a file was last modified, but if what you want to see is when a file's status was last changed, then use the "-c" option. Now, if you're wondering whether permissions or user/group information has been changed recently, then use "ls -ltrc" command to display the files which have changed status most recently at the end of the listing.
Those are just a few of the things that you can do with ls. So, if you're stuck at home on some rainy Saturday afternoon and are tired of the Laverne And Shirley reruns, go amuse yourself -- read the ls manual page, write down all the options, and try them all out. At least there won't be commercial interruptions... :-)
Besides using ls with the "-F" option, there's another very handy utility called file which gives you a indication of what a file actually is.
Every now and then, someone posts a message to one of the comp.os.linux groups asking about how they can determine whether a file is a.out or ELF (or something else, for that matter). If you really do have a mysterious file, then file is the utility for you.
So, let's say that you've come across a file in your /usr/local/bin directory called "d2utxt" and it beats the pants off of you what this thing is. Well, you could try something like:
file /usr/local/bin/d2utxtI've actually got that file on my system and when I run this (from within VIM of course -- notice that my fingers never leave my hand... :-) I get:
/usr/local/bin/d2utxt: Linux/i386 executable or impure executable (OMAGIC)OK, that lets me know that it's some kind of executable. So is it ELF or not? Well, let's run this on a file which I know is ELF and see what happens:
file /usr/bin/vi /usr/bin/vim: ELF 32-bit LSB executable i386 (386 and up) Version 1So, there's your answer! It seems that the d2utxt program was, in fact, a.out format and vim is in our now familiar ELF format. So, if you're wondering what kind of executable format a file is in, this is your solution. And keep in mind that file recognizes a LOT more than simply executables. As an exercise, try running it on a plain text file, a shell script, a *.dvi file, a postscript file, a shared library file, and so forth. I won't go into the specifics of how file works its magic (no pun intended... honest!) but if you're interested, the manual page gives those details.
Keep in mind that the file utility is a VERY useful tool to have at your disposal when you're writing shell programs that depend on knowing what a file's type is.
For example, suppose that you decide to write a shell script to automate file printing. One of the things that your script will need to know is what type of file you are working with. Tex, DVI, PostScript, and plain text files get printed using quite different programs. Here's an ideal situation in which the file program will give you that information.
Again, convince yourself of this by running file against several different file formats -- pretty impressive, eh?
The next bit of information about a file that can often be quite useful is a rather simple one: "Where is it??!!"
If you're trying to find an executable then this task is greatly eased by use of either which or type (if you're using the BASH shell). Either one of these will print the path to a give executable -- assuming, that is, that it is in your PATH statement. So, let's say that you wanted to find out where xdvi was located. Now, you could probably guess, but let's just say that you really were clueless and wanted to know. Well, if you tried something like the following you could find out:
which xdvi /usr/X11/bin/xdvi type xdvi xdvi is /usr/X11/bin/xdviHmmm... that was pretty easy now, wasn't it? Both of these found our file in the /usr/X11/bin/ directory and the output was pretty similar. But before we call this an even draw, suppose that you try to do something like this:
type tarx tarx is aliased to `tar -xvzf' type exec exec is a shell builtinHmmm... interesting.
I won't give you the output that happens when I run which on either of these because what happens is it prints an error message that states that it couldn't find it in... and then prints the entire search PATH. I'll let you try this one at home. Suffice it to say that if you're running the BASH shell, then using type gives you the added benefit of recognizing shell aliases and builtins in addition to executables.
Very handy.
Another useful little item that type can do for you is find duplicate executables. Now before you go scoffing, consider the fact that it is VERY easy to do a bit of "Do-It-Yourself" system upgrading and install a few programs. If you don't know that the program which you are installing has already been installed (but in a different directory) then you end up with two copies. So which one gets executed?
Good question.
Presuming that you don't use absolute path names for executables (e.g./usr/bin/vim) every time you want to start a program, then whichever executable is found first in your PATH statement. So, if you have two copies of elvis (one from an original installation and one from a new compile and install) then the one that is found first is executed.
And how, do you suppose, I know this...?
Believe me, I've done it :-)
And the results can be impressively frustrating.
Specifically, I had upgraded a version of Tcl/Tk a while back and when I ran all my favorite tcl/tk apps I started getting weird messages about version incompatibilities and so forth. So I recompiled and reinstalled and still got those annoying error messages. It was driving me crazy. Finally, I tried running type and noticed that the wish executable wasn't where I thought I'd installed it. The breakthrough came when I tried:
type -a wish wish is /usr/local/bin/wish wish is /usr/bin/wishAh Ha!!
You see, there had been an old copy of a previous version lying around and I had simply forgotten to delete/rename it. The old version was being found first but it was incompatible with the tcl scripts I was using. Renaming the old version cleared things up.
So the moral of the story is that if want to ensure that you have only one copy of a program in the search PATH, then use type -a.
OK, so now you know how to find executables... what if what you're looking for is NOT an executable? What then?
Well, these next two utilities deserve an entire article (and, in fact, got just that in one of the recent issues of the Linux Journal. Both find and locate will allow you to search anywhere in your system for a given file. For the time being, I'm going to use a simple example.
Suppose that I'm looking for a certain configuration file for the lynx program. I've discovered that lynx has a config file that will let me set various options -- but I don't know where this is located except that I have a hunch that it is somewhere in /usr/local/. Great! To find it, all we have to do is:
find /usr/local -name lynx* -print /usr/local/bin/lynx /usr/local/lib/lynx /usr/local/lib/lynx/lynx.cfg /usr/local/lib/lynx/lynx.hlp /usr/local/lib/lynx/lynx.man /usr/local/lib/lynx/lynx_help_main.html /usr/local/lib/lynx.cfg /usr/local/lib/lynx.cfg.color /usr/local/man/man1/lynx.1 /usr/local/src/INSTALLED/lynx2-5FM.color.ELF.tgz /usr/local/src/Incoming/lynx2-6.tar.gz /usr/local/src/Incoming/lynx2-6.color.ELF.tgz /usr/local/doc/lynxYow! Bonanza!
So there we go... find not only located our lynx configuration file but also found that there were duplicates! Interesting :-) So how do we do this for any file? Well, the basic pattern is:
findThat is, the first argument is the directory from which to START looking. Find will automatically traverse all the subdirectories beneath this. So, if you wanted to scour your entire system, you just invoke find as:-name
find / -name lynx* -print
The second argument is "-name" followed by the pattern of the file name you're looking for. And finally, the "-print" option specifies that find should print the results to stdout. Keep in mind, though, that the GNU version of find doesn't need the "-print" option -- it defaults to printing to standard out (your terminal :-).
The other handy-dandy little tool is locate. If this has been set up correctly (that is, that the database of files is routinely updated) then it is a LOT faster to use than find if all you are looking for is a particular file name!
To use it just invoke it as:
locate lynx /home/fiskjm/.lynx-bookmarks /home/fiskjm/.lynxrc /usr/bin/lynx /usr/doc/lynx /usr/doc/lynx/about_lynx /usr/doc/lynx/about_lynx/about_lynx-dev.html.gz /usr/doc/lynx/about_lynx/about_lynx.html.gz /usr/doc/lynx/about_lynx/COPYHEADER.gz /usr/doc/lynx/about_lynx/COPYING.gz /usr/doc/lynx/CHANGES.gz /usr/doc/lynx/CHANGES2-3.gz /usr/doc/lynx/CHANGES2-4.gz /usr/doc/lynx/CMU.announce.gz /usr/doc/lynx/CRAWL.announce.gz /usr/doc/lynx/DESC.gz /usr/doc/lynx/docs /usr/doc/lynx/docs/README.html.gz /usr/doc/lynx/docs/README.txt.gz /usr/doc/lynx/docs/RFC-MAILCAP.txt.gz /usr/doc/lynx/FM.announce.gz /usr/doc/lynx/IBMPC-charsets.announce.gz /usr/doc/lynx/INSTALLATION.gz /usr/doc/lynx/lynx_help /usr/doc/lynx/lynx_help/keystroke_commands /usr/doc/lynx/lynx_help/keystroke_commands/bookmark_help.html.gz /usr/doc/lynx/lynx_help/keystroke_commands/dired_help.html.gz /usr/doc/lynx/lynx_help/keystroke_commands/edit_help.html.gz /usr/doc/lynx/lynx_help/keystroke_commands/gopher_types_help.html.gz /usr/doc/lynx/lynx_help/keystroke_commands/history_help.html.gz /usr/doc/lynx/lynx_help/keystroke_commands/keystroke_help.html.gz /usr/doc/lynx/lynx_help/keystroke_commands/movement_help.html.gz /usr/doc/lynx/lynx_help/keystroke_commands/option_help.html.gz /usr/doc/lynx/lynx_help/keystroke_commands/other_help.html.gz /usr/doc/lynx/lynx_help/keystroke_commands/print_help.html.gz /usr/doc/lynx/lynx_help/keystroke_commands/scrolling_help.html.gz /usr/doc/lynx/lynx_help/keystroke_commands/xterm_help.html.gz /usr/doc/lynx/lynx_help/lynx_help_main.html.gz /usr/doc/lynx/lynx_help/Lynx_users_guide.html.gz /usr/doc/lynx/PROBLEMS.gz /usr/doc/lynx/README.gz /usr/doc/lynx/RELEASE_STATEMENT.gz /usr/doc/lynx/samples /usr/doc/lynx/samples/jumpsUnix.html.gz /usr/doc/lynx/samples/jumpsVMS.html.gz /usr/doc/lynx/samples/lynx.cfg.gz /usr/doc/lynx/samples/lynx.com.gz /usr/doc/lynx/samples/mailcap.gz /usr/doc/lynx/samples/mime.types.gz /usr/doc/lynx/SOCKETSHR.announce.gz /usr/doc/lynx/TCPWARE.announce.gz /usr/doc/lynx/userdefs.h.gz /usr/doc/lynx/VMSWAIS.announce.gz /usr/lib/lynx /usr/lib/lynx/lynx.cfg /usr/lib/lynx/lynx.hlp /usr/local/bin/lynx /usr/local/doc/lynx /usr/local/doc/lynx/LynxUser.guide.gz /usr/local/lib/lynx /usr/local/lib/lynx.cfg /usr/local/lib/lynx.cfg.color /usr/local/lib/lynx/keystroke_commands /usr/local/lib/lynx/keystroke_commands/bookmark_help.html /usr/local/lib/lynx/keystroke_commands/dired_help.html /usr/local/lib/lynx/keystroke_commands/gopher_types_help.html /usr/local/lib/lynx/keystroke_commands/history_help.html /usr/local/lib/lynx/keystroke_commands/keystroke_help.html /usr/local/lib/lynx/keystroke_commands/movement_help.html /usr/local/lib/lynx/keystroke_commands/option_help.html /usr/local/lib/lynx/keystroke_commands/other_help.html /usr/local/lib/lynx/keystroke_commands/print_help.html /usr/local/lib/lynx/keystroke_commands/scrolling_help.html /usr/local/lib/lynx/keystroke_commands/xterm_help.html /usr/local/lib/lynx/lynx.cfg /usr/local/lib/lynx/lynx.hlp /usr/local/lib/lynx/lynx.man /usr/local/lib/lynx/LynxStartFile.html /usr/local/lib/lynx/lynx_help_main.html /usr/local/lib/lynx/Lynx_users_guide.html /usr/local/lib/lynx/new_installs.html /usr/local/lib/lynx/readme.html /usr/local/man/man1/lynx.1 /usr/local/src/Incoming/lynx2-6.color.ELF.tgz /usr/local/src/Incoming/lynx2-6.tar.gz /usr/local/src/INSTALLED/lynx2-5FM.color.ELF.tgz /usr/man/man1/lynx.1.gz /var/log/packages/lynx /var/X11R6/lib/config/lynx.cfYIKES!!
On my system, this took about 1 second to display and it printed the location of EVERY instance of "lynx". Now, for some reason which I haven't figured out yet why this doesn't work the way the manual page indicates that it should. Maybe your system works better than mine... :-)
The way that it should work is that you give locate a filename pattern which it searches for. Such as:
locate lynx*
However, when I tried this on my system, it simply returned nothing. Using locate lynx worked like a charm.
Got me.
Keep in mind, too, that find is a seriously powerful search tool that has all kinds of options that let you do sophisticated searches. You really do need to check out the article that recently appeared in the Linux Journal. I'm sorry that I can't recall offhand which issue it was in, but the LJ has put a number of articles online on the Web and so you might try looking at their web site for information.
Finally, here's a nifty little trick that let's you see what shared libraries a file is linked against. If you've ever wondered whether a file was statically or dynamically linked, then here's your answer!
Just invoke ldd with the name of the executable and it will print out a listing of all the libraries that it is linked against AND where these libraries are located on your system.
So, for example, running ldd against gvim (Graphical VIM), I get the following output:
libXm.so.2 => /usr/X11R6/lib/libXm.so.2 libXt.so.6 => /usr/X11R6/lib/libXt.so.6 libSM.so.6 => /usr/X11R6/lib/libSM.so.6 libICE.so.6 => /usr/X11R6/lib/libICE.so.6 libXext.so.6 => /usr/X11R6/lib/libXext.so.6 libX11.so.6 => /usr/X11R6/lib/libX11.so.6 libncurses.so.3.0 => /lib/libncurses.so.3.0 libc.so.5 => /lib/libc.so.5.3.12 libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4
pretty nifty, eh?
Anyway, if you've ever picked up a pre-compiled binary and it just simply won't execute, try running ldd against it to ensure that all the needed libraries are being found.
So, that should do it!
I'm sure that there are many other tricks and means for prying information out of an obscure file. As a parting note, if you've ever wondered just exactly what a file does then you can try a couple things. The first is to see whether there is a manual page for the program. That's usually a good source of information. The other maneuver you can try is simply something like:
prog --help
Presuming the program's name was "prog", then frequently using a command line option such as "--help" will print a help message. Also, a number of programs will, if they don't recognize a command line option, go ahead and print a short usage statement anyway. If you're in the dark, give it a whirl!
If you'd like,
drop me a note at:
Version Information:
$Id: wkndmech.html,v 1.1.1.1 1997/09/14 15:01:36 schwarz Exp $
![[ TABLE OF CONTENTS ]](../gx/indexnew.gif)
![[ FRONT PAGE ]](../gx/homenew.gif)
