|
|
|
|
| Terminal Basics |
| Written by Bruce Brown | ||||||||||
| Tuesday, 05 December 2006 | ||||||||||
|
Alternative modding
Getting Your Feet Wet In this column, we're going to explore the Unix underpinnings of your Mac and tap into the vast modding potential it has to offer. As we've seen in Tom Mordasky's DotAPP, software can customize your system just as much as a rotary tool can. However, instead of dealing with various published software titles on the web, we're going to learn how to mod our software from scratch. In doing this, I'm going to make several assumptions. For instance, I'm going to assume that you're running some version of Tiger, although most, if not all, of what I write here should apply to Panther and earlier versions of OS X as well. I'm also going to assume you've had at least some minimal exposure to Unix. I'll assume that you've launched the OS X Terminal application (below) at least a few times already, and have already succeeded in running a few basic Unix commands there. 
If not, there are many good books on Unix; in particular check out Learning Unix for Mac OS X Tiger by Dave Taylor, from O'Reilly, and Ted Landau's Mac OS X Help Line by Ted Landau and Dan Frakes, from Peachpit Press. Although the Landau book isn't specifically about Unix, it does include a chapter or two on Unix, plus lots and lots of other "under the hood" goodies. Anyone who maintains Macs, mods them or works with Unix on Macs should have this book. Another good source of information is the Help included in Terminal: From within Terminal, select Help > Terminal Help. Then, in the Help Viewer, click on "Learn about Terminal." From the Learn about Terminal page, you could just browse around the Help pages, or you could click on the "UNIX Basics" link. That will take you to a page with task-oriented links. For example, if you wanted to copy a file, but didn't know (or couldn't remember) that the Unix copy command is "cp," clicking on the "Copying a File" link will display a page with a brief summary of the cp command. To get the most out of this column, some of the things you should already know about are: how to display the "man" page entry for a command, how to list the contents of a directory, how to display the setting of the current directory, and how to change to a different directory. You should also understand a little about the concept of pathnames in Unix, understand a little about Unix file permissions, and so on. It'd be good if you understand a little about Unix processes, too. In my examples in the text, I'll use the '$' character to indicate a Unix prompt (which appears in a window in Terminal). In my screen shots, you'll see a longer prompt that ends with the $ character. Your actual command prompt might use a different character, such as a '%' character. Also, your prompt is likely to be a longer string of characters that includes other info, such as the name of the current directory. When entering Unix commands listed in the examples, remember not to type the $ character, or anything to the left of it on the same line. Also, I'll often include comments at the end of each command line in my examples. These, too, are not to be entered; they're just there for explanation of what's going on. I'll start the comment portion of the line with a # character, so don't type that # character, or anything to the right of it on the same line. Here's an example below:
In the above example, you'd type only the text "somecommand" (but without the quotes). The '$' sign and the text that starts with, "# Here's just some sample ... " are not to be typed in. Before we get into playing around with Unix, though, let's set down a few commandments, with an eye toward avoiding data loss or causing any other serious system problems with our Macs. You might want to clip and save this part of the column, and use it for future reference, during your Unix explorations. Rules of the Road Back up, back up, back up! 'Nuf said! The safest and best backup approach, for our purposes here, is to make a complete "clone" copy of your hard drive before you go modifying any of the system files on it. That way, you have a copy of everything, should you need anything later. I am not responsible if you screw up! It's also a good idea to back up any Unix text file before you edit it (more on this later). Listing a directory: Use "ls -al," not just "ls" to list a directory. When in doubt, always use a command that displays _all_ of the files and directories in the directory, including those whose names start with a dot. Also, be sure to use a command that displays the file permissions info for each file and directory listed. The "ls -al" variant of the Unix ls command meets both of these requirements. You might not always think you need the extra info, but better safe than sorry (and, it's easy enough to list only a portion of the directory, after you've listed the whole thing). As a side benefit, looking at all the files in the various directories you visit on your hard drive can be a learning experience, because sometimes just knowing something exists, or just knowing where it's kept, is half the battle. Example:
Here's what the above example would look like on your screen: 
Changing directories. When changing to a different working directory (the "cd" command), don't rely solely on the pathname being displayed correctly in the Unix command prompt. One reason for doing this is that the command prompt doesn't always display the entire pathname, such as when the pathname is very long, a common occurrence. This truncated pathname can sometimes be misleading. Once you've cd'd to the new directory, immediately use the "pwd" (print working directory) command to display the full, current pathname. Compare this pathname to the pathname portion of the command prompt. If they're the same, all well and good. If not, at least you can make a mental note that they're different, then proceed accordingly. Using the pwd command also gets you a nice, clean copy of the pathname on a line by itself, which can be useful if you later want to copy the pathname and paste it somewhere. Example:
Here's how that might appear on your screen: 
Editing Unix text files Unix uses plain text files for lots of different purposes, including storing configuration information and settings for various parts of the system. Sometimes you might want to modify some of those text files. Here are some suggestions: First and foremost, always make a backup copy of any Unix text file before editing it. In nearly all cases, it takes only a small amount of your time and an infinitesimal amount of disk space to do this. If you end up never using this backup copy, little harm is done, as many text files simply aren't all that big. If you think you might ever need the backup copy again, it's usually best and safest to just leave the backup copy on your drive after you're all done. With time and experience, you should be able to better judge when to delete an unneeded backup copy of a text file, so it doesn't clutter up your drive, and when to just leave the file there indefinitely. Of course, if you made a backup copy of your entire hard drive before you started, you could find a copy of the original version of the text file you've changed somewhere in the backup data. But, it's usually more convenient to have a backup copy of just the text file itself nearby. You'll also need to know the settings of the file permissions on any text file before you edit it, so that you can put things back the way they were, if need be. Probably the easiest way to do this is just to copy the file you're about to edit to the SAME directory, giving the copy a slightly different name in the process. Copying a file to the same directory using the Unix "cp" command normally causes the copy to have the same permissions as the original, thereby preserving a backup copy of both the file's contents and its permissions. Example:
Here's how this looks on screen: 
Though there are many command-oriented text editors for Unix (vi, vim, emacs, etc.), I recommend that you use a GUI text editor to edit Unix text files whenever possible. The Mac OS X TextEdit application that you already have is perfectly acceptable for this. If you want a more powerful GUI text editor, with more bells and whistles than you might ever need, I recommend the free TextWrangler application from Bare Bones Software. Editing text files that have their permissions set to not allow administrators (or others) to change them. In other words, root access is needed to edit them. Sometimes, you might need to edit a text file, but not have the proper Unix permission to modify the file. In that case, assuming you do at least have an OS X account with administrator privileges, you can choose one of the methods to accomplish this: Method 1. Make a note of the file's current permissions. (You could use the "ls -al" command to display the current permissions.) Temporarily change the permissions to allow you to edit the file, edit the file, then change the permissions back to their original settings. (You could use the "chmod" command to change the permissions.) Method 2. Use the Unix "sudo" command and the "open" command to launch your favorite OS X GUI text editor from the Unix command line. That will give the text editor root privileges for only that edit session (until you Quit the editor). Now, edit the text file in that GUI editor (so that you don't accidentally modify a crucial file while the editor is running with root privileges). Quit that editor. Here's an example of using the sudo command to launch TextWrangler with root privileges and edit a text file; by simply changing the application name from TextWrangler.app to TextEdit.app, you could use TextEdit instead:
[At this point, TextWrangler will launch with root privileges. If you also included the name of the text file at the end of the command, as shown here, TextWrangler will also open that file, ready for you to edit it.] Here's how this looks on screen: 
TextWrangler will then launch, come to the front, and display the text file, ready for you to edit: 
Method 3. Use Brian Hill's third-party utility Pseudo to launch your favorite GUI text editor with root access. Method 4. Enable the root account. Log in to the root account in OS X, use your favorite OS X GUI text editor to edit the file, then log out of root. Disable the root account. Although this method will work, I don't recommend it. It's better to use one of the other methods that don't require you to enable the root account. One problem with enabling the root account is that you might forget to disable it when you're done using it! Leaving the root account enabled continuously is somewhat of a security risk, so it's best to avoid this approach whenever possible. Processes Avoid killing any process whose purpose you don't know! In Unix, roughly speaking, a "process" is any running program. All OS X applications cause at least one Unix process to run when the OS X application is launched. But, not all processes are OS X applications. In other words, the category "process" is a broader, more all-encompassing, category than is "application." The usual way to kill a process from the Unix command line is with the Unix "kill" command. More on this command in a later column. For now, just remember this: Killing an unfamiliar process you don't understand, and whose purpose you don't know, could cause your system to crash. Or, worse, it might even cause corruption to files on your hard drive. Killing an unfamiliar process is a little like sitting on a tree branch, then sawing off the branch between you and the tree! Files, Folders, and Directories Create a subdirectory in your Home OS X folder for all of your Unix experimentation. Name it something distinctive like "playground" or sandbox," so that you know what it's there for. a separate folder for your Unix stuff will tend to contain any problems if something goes wrong. It's not a cure-all, though, so you still need to pay attention to the other cautions in this list, especially regarding making backups before you start. Example:
Here's how this looks on screen: 
Next Up For the next installment in this series, we'll learn how you can rename your Trash icon in the Dock. This is a relatively safe modification, as its result is only cosmetic, yet it'll give you a chance to make a simple modification to your Unix system, in an area of your hard drive where ordinary users never go. From there, in future columns, we'll branch out in other under-the-hood directions. Till then, keep moddin!
Write Comment |
||||||||||
| < Prev |
|---|
|
|