Teach Yourself Unix in 24 Hours 250
Spencerian writes "The surge of Unix-derived operating systems such as Mac OS X, Linux, and the now-free Solaris is not slowing against the fortified but embattled breakwaters of the Microsoft operating system family. But new power users of other operating systems, including those just starting with Unix as well as the graphical interface of the operating system (such as the Mac OS Finder, or the navigators of KDE or Gnome), remain in need of a comprehensive primer for Unix that complements their previous knowledge. The fourth edition of Dave Taylor's "Teach Yourself Unix in 24 Hours" should remain on the top of the buy list for computer users in need of a strong Unix reference where they may find themselves managing or using the subtle variants of Unix flavors." Read the rest of Spencerians' review.
Sams Teach Yourself Unix in 24 Hours, 4th Edition | |
author | Dave Taylor |
pages | 518 |
publisher | Sams Publishing |
rating | 7.5 of 10 |
reviewer | Kevin H Spencer |
ISBN | 0-672-32814-3 |
summary | The fourth edition of Dave Taylor's "Teach Yourself Unix in 24 Hours" should remain on the top of the buy list for computer users in need of a strong Unix reference where they may find themselves managing or using the subtle variants of Unix flavors. |
The format of this Sams book, as with other books in this "Teach Yourself...In 24 Hours" series has not changed. The book content does favor Windows or Macintosh users when describing, comparisons and contrasts of Unix tasks to those popular operating systems. Unless the reader has been a fan of very little-used operating systems in their past and somehow managed to avoid Mac OS, Windows or Linux, absorption of what is needed for each chapter shouldn't be difficult.
Each chapter is technically noted as a one-hour lesson, although the author acknowledges that many may need more than one hour to absorb some material and should take as much time as they need to understand what they need to know. Chapters include the Unix basics such as using text editors such as vi, moving and copying files, viewing file contents and locating files in the operating system, and topics scale upward to advanced shell programming and even Perl programming. Generally, most readers need not read from beginning to end, chapter to chapter. Despite the lesson-like mode of the book, "Teach Yourself Unix" is a reference.
The "Teach Yourself" books are not advanced reference books, however, and "Teach Yourself Unix in 24 Hours" is no exception. As someone that's used more and more Unix commands in the background of Mac OS X to make things easier or to circumvent limitations or flaws of the Mac OS X Finder, the previous editions of "Teach Yourself Unix" were handy references when I needed a quick and certain process to accomplish a task. Sometimes it's too easy for graphical interface users to moan and while when the Windows Explorer or Mac OS X desktops stick and slows to a crawl when managing something as simple as copying a file, forgetting that there is another way. This book contains the basics to manage these tasks without being too basic of a reference.
The author's breadth of knowledge in many Unix-derived systems such as BSD, Solaris, and Linux continue to extend themselves well in the lessons. Each chapter contains explanations and examples to aid those that need more information. Most Slashdot readers might find this level of detail a bit plodding, but some newbies to Unix may need this since Unix is not inherently a graphical operating system that's easy to understand by sight, so things need to be literally spelled out. Peppered throughout the book are sidenotes that keep the reader apprised of exceptions or proper etiquette when handling, discussing or pronouncing Unix tasks and terminology.
There's a marginally useful amount of back matter on the book, consisting of two appendices, one on frequently-asked Unix questions, and another more useful appendix on managing the Apache web server from a command line. The back cover has a simple command-line reference that's not bad, however, being Unix, the amount of commands and versatility seem a bit limited, so the command-line reference lacks a bit of punch. Some chapters seem a bit archaic and probably need to be reconsidered in a future edition--very few of us may have a need to send mail from the command line in this age of Yahoo Mail and the sheer number of mail services available on computers in schools, businesses, homes, and even from cell phones for jotting off a quick note to a comrade for quick answers. Full-time conversing by mail in Unix isn't something I feel anyone but the most hardcore Unix user will relish--and those users aren't the audience of this book.
This book is designed for new Unix users, but intermediate users will find "Teach Yourself Unix in 24 Hours" a handy reference when having to workaround GUI pitfalls or failures. This book's previous versions have saved my bacon in reinforcing my previous experience and skills at the command line when the Mac OS Finder seizes, leaving no graphical way to complete a task. Unfortunately, given the volume of information I must remember in using both Mac OS X and Windows XP, I, for one, can't remember every nuance of Unix needed, particularly since it's not as easily remembered as icons or menus. Perhaps the author may find that a fifth edition will need information on the long-awaited Windows Vista in the event it contains Unix parts and pieces."
You can purchase Sams Teach Yourself Unix in 24 Hours from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
work with someone knowledgable... (Score:5, Informative)
Step #1 (Score:4, Informative)
The Difficulty (Score:5, Informative)
The problem is that many people who first start out with the command line seem to view it as more of them having to simply type in obscure commands to correspond to the same steps they would take were they using a GUI. I've seen many people type: instead of simply typing mv ~/foo/foo.txt ~/bar.txt Of course this is a simple example, but I think that it illustrates my point that people are often locked into the GUI mindset. As such, even if they understand in the abstrace the use of piping and output redirection, etc, the difficulty is in understanding how to use those tools efficiently.
Save $10.20! (Score:0, Informative)
Re:It's on my bookshelf next to... (Score:4, Informative)
Its pretty well thought and explained to be able to teach yourself .
In 24-hours? Not unless your a crazed, methampthetamine monkey with an IQ of 180 and a degree in speed reading, not too mention the ability to type ~200 wpm.
More realistic would be 1-3 hours per lesson, 3-5 lessons per week.
Each 'hour' in the book is one 'lesson', and there really is no reason to try and complete each lesson in one hour; far better to go over it and make sure you grasp it, and to just generally take it at a relaxed pace.
Best intro to Linux book out there... (Score:2, Informative)
There are many books about UNIX internals. (Score:4, Informative)
They explain how each portion of the system works, in addition to how they work together. And then they explain exactly why.
You should be able to find such books at a university bookstore.
Re:My problem with "learning Unix" (Score:3, Informative)
The BIOS (also called "boot prom" on some systems like Suns) loads a bootloader (one of GRUB, LILO, SILO, etc.) which loads the kernel which runs a special program called init. Depending on the flavor of Unix (System V vs BSD types), it either reads /etc/inittab and executes scripts found in there, or starts executing the script /etc/rc.
So, once you can read shell scripts, you can follow the whole chain of system startup from there. Some examples of the System V influenced Unixes are Solaris, and most distributions of Linux. BSD types include Free/Net/Open BSDs and old SunOS (before it was called Solaris).
There's a concept called "run levels" which you'll need to understand (basically tells the system whether it's booting up to full multiuser mode, shutting down, running single-user system maintenance mode, whether or not to automatically start the graphical user login - as opposed to text mode login). init controls the system as it goes from one "run level" to another, executing the scripts that start or stop system daemons ("services" in Windows terms). Running the command "man init" will give you the details of how init works on your particular system.
If I do work this up into a fuller description, I'll post a link in my journal, so check there in a few days.
Re:My problem with "learning Unix" (Score:2, Informative)
Wow! You're a born Unix person. Really. Windows was made for people who don't care how it works, Unix was made for people who do. You're a perfect fit.
Unfortunately, the current crop of Unix advocates are too busy trying to shield the potential newbie from the "why" to realize how important it really is. If the "why" scares the newbie, then they're not a good fit for Unix, so we shouldn't be trying to fit them into an OS that they won't like.
Does anyone know any books that address the "how it all works together" part?
Someone else mentioned "Design and Implementation of *BSD", but that's too hardcore for your needs (unless you're a developer and are keenly interested in the inner workings of kernel data structures). I'm going to point you in other directions instead.
First, check out the set of newbie documents for FreeBSD, http://www.freebsd.org/projects/newbies.html [freebsd.org]. More technical, but much less so than the Design book, is the FreeBSD Architecture Handbook, http://www.freebsd.org/doc/en_US.ISO8859-1/books/
Re:My problem with "learning Unix" (Score:5, Informative)
The hardware runs a program. That program loads the kernel and executes it. Any more specific, and you're now talking platform-specifics which don't have to with UNIX.
For example, Linux on a DEC Alpha might boot like this:
- Windows NT ARC loader configured to spawn program MILO.EXE on FAT-formatted disk in Drive A:
- MILO.EXE understands Linux ext2fs, and launches the kernel wherever the Windows NT ARC loader's environment variables tell it to find it. (Hint - it's faster if you point it at a harddisk). The kernel is generally called
Another example, Solaris on a SPARC box might boot like this:
- The EEPROM stores the identity of the boot partition
- The PROM loader goes looking for the boot blocks (installboot (1M)) on that partition, and executes the code it finds there
- The software just executed understands the Unix Filesystem (UFS), goes looking for the kernel where it belongs (set by the installer, I forget where it's written down). Traditionally, it was
- The kernel looks in
Solaris on an x86 box boots pretty much like windows.
- The BIOS goes looking for the first "active" partition, as marked by the disk partitioning utility. Generally on the first IDE controller's master disk.
- The BIOS executes the code in the master boot record (MBR), which somehow winds up loading the boot blocks.
- The software just executed understands the Unix Filesystem (UFS), goes looking for the kernel where it belongs (set by the installer, I forget where it's written down). Traditionally, it was
- The kernel looks in
> How does it interact with hardware?
Same as any other operating system; through the PCI/ISA/etc bus and the API implemented by the hardware.
> Is there a general hint to what all the directories are
> about or any memory aids for knowing what's in them?
Keep in mind, UNIX is not Windows. Generally speaking, you can put anything anywhere you want, as long as you change everything which cares about it. Which is usually possible!
Keep in mind also, that nothing is absolute.
> Permissions - any chance of an overview of what the bits mean,
Permissions are most useful to examine as four-digit octal numbers. Assign each octal digit as such: SOGW
S - Special stuff, like sticky bits. Almost always 0
O - Permissions for the file owne
I found the third ed. useful. (Score:3, Informative)
Re:My problem with "learning Unix" (Score:3, Informative)
I only really know how Linux boots at an overview, but other *NIX systems may be very similar. There is something called a "boot loader" that sits at the beginning of the boot disk and points to the Linux kernel. The linux kernel then takes over the machine in terms of getting an inventory of the hardware attached on the computer and initializing the device drivers and the devices. It then looks for
That in no way is very comprehensive, but its pretty much sums things up. I don't know if this is still the case, but I used to make linux bootable disks simply by doing "cat kernel_image >
How does it interact with hardware?
Depends. It just "does the right thing(tm)". Just kidding. I'm not sure what you are asking here in terms of how do you manipulate hardware via the OS, or how the OS internally handles the hardware. Both are too large of a topic to talk about here.
Is there a general hint to what all the directories are about or any memory aids for knowing what's in them?
Most of this is Linuxcentric, but many things apply to other systems as well.
I always put just about everything in my path, because some of the directory naming conventions are ambiguous or whatever (like traceroute being in
There is
Now there is
Re:My problem with "learning Unix" (Score:3, Informative)
Some others have given some really good explanations on most of these questions, I'll try explaining a little more about the way the system deals with hardware.
The operating system kernel is this part of it that runs all the time and takes care of the scheduling of the various processes and of servicing the requests that these have for access to disks, keyboard, mouse, screen, serial ports, network ports, printers and so on. Since there is a lot of different varieties of these, the operating system uses a set of suitable drivers for each device. The devices and their associated drivers are of three major kinds: there are character devices, that work with streams of characters, such as the keyboard or the screen or the printer, and there are block devices such as disks, that deal with large chunks of data. The third kind of device are network interfaces that are not classified as traditional block or character devices at all.
The block and character devices are identified in the systems with their "major number". In older unix systems, there was two master tables of these device numbers, that indicated that for example character device number 1 would be a console, block device number 7 would be some kind of disk and so on.
On Linux systems, the same idea of major numbers are used, but the device driver programs usually request their own major numbers themselves, and the kernel builds these tables on boot, and we can see what this becomes through the pseudo-file /proc/devices.
Programs in the "user-space", that is all programs that we normally run as processes ourselves, have to access these devices through "node files", normally located in the /dev directory. When reading or writing to a device through these files, the operating system routes the requests for reading and writing to the appropriate driver since it knows the major number. Each driver provides a read() and a write() function to the kernel code that it calls for the device-driver to do its job. Both character and block devices may be read and written as if they were disk files, the block devices hold filesystems, and can additionally be mounted, and thus made accessible through a directory somewhere in the system.
The node files in /dev indicate a filename of a device, its major number, its minor number (this is used to tell several different devices of the same type apart), and of course whether this is a block or character device. On a long listing, (ls -l) the prefix shows as b or c for block or character device. Like other files, these may have read/write permissions set to control who may read or write the files. Most of them are owned by root. It is possible to create such node-files elsewhere in the file system, but that tends to be frowned upon.
In the above, very short, excerpt from /dev on this machine, we see the hard disk is block device major number 3, and the serial ports are character devices major number 4.
There is usually a whole slew of such node files under /dev, and they come in long series of names, beginning with some short prefix such as tty, pty, sda, hda, fd and so on. Generally, these prefixes follow a convention:
tty are serial lines, terminals, or consoles, (the abbreviation comes from "teletype"); pty are "pseudo-tty" devices, basically a kind of pipe that look much the same as a real tty to the programs reading and writing to them. Another character device of interest is the lp series, these are the parallell ports as used for printers.
fd ar