Originally Published: Friday, 16 June 2000 Author: Rob Bos
Published to: featured_articles/Featured Articles Page: 1/1 - [Std View]

Stuff I Learned This Week

Using Linux is a continual learning process. A person finds new and interesting ways to use the tools they have at their disposal very often. On my Debian system are 1226 individual commands; my total vocabulary consists of perhaps two hundred of them. There is plenty of room to learn and grow.

Using Linux is a continual learning process. A person finds new and interesting ways to use the tools they have at their disposal very often. On my Debian system are 1226 individual commands; my total vocabulary consists of perhaps two hundred of them. There is plenty of room to learn and grow.

That said, here's a couple neat things I learned this week:

Tar doesn't have to be used just for extracting downloaded files; you can also use it to write archives as raw data to a device. For instance, doing a tar cz foo/ > /dev/fd0 will create a gzipped tar file as output; then send the output as raw data to the floppy disk (or tape drive, or hard drive, or whatever). Then, when you want to extract the data:

tar zxvf /dev/fd0

Very neat, hmm? Reformatting the floppy isn't required, no special tools, just create the file and stick it on to the disk. This is useful for situations where you need to transfer small files between computers where one does not have a network connection available, or in any number of similar situations.

Sending the output to a file, tar cz foo/ > foo.tar.gz gives us even more flexibility. If, for instance, foo.tar.gz is a multi-hundred-megabyte backup of very important data, it's possible to literally burn that tarball to a CD and be able to extract it very easily using tar zxvf /dev/cdrom, or use tar's various options to search the compressed archive for particular files and so on. In situations where you want to split a file across multiple floppies, you can use split to break the tar.gz file into several floppy-size chunks and then dd if="foo(part1).tar.gz" of=/dev/fd0 the chunks of the file, using dd to retrieve and rebuild the file piece by piece on the other end.

Taking that idea one step further, we can pipe tar's output directly into the CD burning program; for example, tar zxf foo/ | cdrecord -v -data - or something similar. This gives you a compressed backup, written directly to CD, that you can access just as you would a normal tar.gz file -- only the "file" is actually /dev/cdrom.

Such simple programs can do very, very unsimple things with little effort. Simple programs, since they are clearly defined, can do small things and do them very well. It's far easier to make a program that does exactly one thing (say, play an audio file) than to make a program that does a hundred things (play an audio file, do cutesy little animations on-screen, provide plugins, be skinnable, have lots of menus, etc). Such simple programs are correspondingly easier to maintain and use; they are more robust and defined.

Another neat (but largely useless) thing that you can do is a direct serial-to-serial connection between machines. Take a fairly mundane serial cable, 12-pin female on both ends, and hook it up to ttyS0 on both computers. On one computer, do cat /dev/ttyS0 and on the other, do echo Hello World! > /dev/ttyS0. Voila, instant communication between two computers, useful perhaps for transferring text files and other various and sundry things. Raw data sent straight from one computer to another, no error checking, no nothing. Very simple.

From this basic step, we can (for instance) use pppd to establish a PPP connection between the two computers and transfer files with error checking and compression using standard network utilities (run ftpd on one computer, ftp to it).

One possible application of this idea might be to use tar to output compressed data to ttyS0; that is, tar cz foo/ > /dev/ttyS0 on one computer, and tar zxvf /dev/ttyS0 on the other -- a painless file transfer (this may or may not work, I haven't tried it).

Taking this idea one step further, it should be relatively easy to do this with a parallel cable, which can handle a lot more data at higher speeds, or even maybe a USB crossover cable. It might even be doable with a straight Ethernet connection, but I've no idea how to go about it.

The idea is the important thing, however. Unix is incredibly flexible, and the concept of abstracting devices to files is a thing of beauty that makes this possible. It may not be perfect, and devices aren't abstracted as well as they could be (where's /dev/eth0, or /dev/X11, for instance), what does exist is well done and useful.

In the Stupid X Tricks department, I found out today that X can easily rotate its display counterclockwise or clockwise. As I type this, I have my monitor turned on its side, and the display rotated ninety degrees. I find this amusing. Simply put the line Option "Rotate" "CW" in your XFree86 4.0 XF86Config file in the Device section for the video card that you're currently using. This will not work with XFree86 3.3.6, however. Right now, I effectively have a 768x1024 display. My monitor just happens to be tipped over on its side. One of the Linux.com staffers remarked that I have to be voiding some warranty somewhere, but I don't care at this point.

This illustrates another interesting point. Since XFree is a completely independent subsystem, as opposed to being tightly integrated with the core operating system, it is free to concentrate on feature enhancements and things that would be otherwise impossible for projects of larger scope. If XFree86 had to worry about creating a window manager, or writing applications, or any of a number of irrelevant things, they would not be able to produce such a solid foundation for other applications. XFree86 is nothing more than an advanced graphics display program capable of sending its display output anywhere, whether it's a local screen or a terminal in Paraguay. Nothing more. It does this thing, and it does it as well as it can, without irrelevant feature bloat. With Linux' growing popularity, XFree86' driver support can only get better and better; with recent enhancements to the way it handles certain fundamental things, it is getting faster and better at handling memory.

Another nifty thing I found this week was the apt-cache program; a utility that comes with the Debian APT system for handling packages. With this program you can search your cache of programs, list information about a given package, find out who maintains the package, and a large amount of useful information.

Linux is nifty. Have fun.

Rob Bos (rbos@linux.com) is a writer for Linux.com. He recommends Linux.com TuneUp for interesting tips very similar to these, and lots of other useful information.