|< Day Day Up >|
Even though you might think that you'll never have a reason to use anything other than a GUI text editor such as Alpha or BBEdit, there are a few arguments to be made for text-only mode editing in a terminal. Among them are that the text-only editors can be used even when the system can't display a GUI interface, and that an editor in a terminal can start much faster than most GUI editors. There's also the advantage that if you have occasion to work on Unix machines other than Mac OS X boxes, the command-line editors are what you will have available.
Finally, at this point, the GUI clients available currently seem to have a bit of a problem figuring out whether they should convert a file that they load into Mac-style text (for newlines) or Unix-style text. The Unix command-line editors are a bit more predictable in preferring Unix-format text. Because of this, if you're working with files in the traditional-Unix side of the system, you're probably safer sticking to the command-line editors.
When it comes to editing text on the Unix side, you'll find that many Unix programs use text files as input, create text files as output, or are configured using commands and variables set up in text files. To change the contents of these files, you'll need to use a text editor.
As a matter of fact, most Unix software doesn't know the difference between a text file and any other file. Unlike in Mac OS, from the point of view of Mac OS X's underlying Unix system, files are files are files. If the user chooses to view some of them as containing text and some as containing programs, that's the user's business. An interesting consequence of this lack of concern about a file's contents is that the operating system is just as happy to allow you to use a text editor to edit the contents of your spreadsheet program itself as it is to enable you to attempt to run your email mailbox. Of course, if you actually have execute permission turned on for your email and try to run it, it's almost certainly going to result in nothing more interesting than a bus error and an immediate exit of the command but the operating system will try to do as you command.
If you spend much time discussing Unix editors with longtime Unix users, you'll find that there is a disagreement of warlike proportions between the users of the two most common editors: vi and emacs. Although these editors are actually rather complementary in their functions and are both useful tools to have in your toolbox, chances are that you will run into many users who insist that one or the other editor is completely useless. If you listen to them, instead of keeping both tools handy, you'll be depriving yourself of the better solution to at least some tasks.
Many Unix editors have immense power. emacs, for example, not only contains its own built-in programming language but can also function as a complete windowing system, a compiler/debugger interface, a news reader, and many other things. Even with a book of this size, however, there isn't space to do more than address the basics of using these editors. After you've mastered the basics, if you're interested in learning more, we encourage you to stop by your local bookstore or library and choose from among the several books available on each of the major Unix editors.
Quick, Dirty, and Omnipresent: vi
The vi editor is Unix's most universal editor. Some users pronounce it vee-eye, and some pronounce it vye, and a growing contingent claim it's pronounced six, when used on Mac OS X. There seems to be no concrete consensus which pronunciation is correct (but the people who say vye are still wrong). vi isn't an easy editor and it isn't friendly. It is, however, a quick-starting editor with a small memory footprint, which you will find on every Unix machine you encounter, regardless of flavor. vi, although annoying to learn, is frequently the most convenient editor to use for doing things such as making single-line changes to configuration files.
When trying to use vi (or vim), there are a number of things you need to know to make it useful.
vi operates in one of two modes: command mode or insert mode. In command mode, you have control over things such as cursor position, deleting characters, and saving files. In command mode, every keyboard character you type will be interpreted as part of a command of some sort. In insert mode, every keyboard key you type is inserted into the file you are editing. This distinction is bound to be confusing at first, but if you use vi, you'll find that its speed makes it a preferred editor for quick changes to files. You will find the Return key included in the explanations here because some commands take effect immediately, and some require you to press Return after you enter them.
Table 13.10 shows some of the most used keys and tasks. If you're just coming to vi for the first time, don't look too long at this table yet; it will just look confusing! Flip past it to the short example of how to use vi and then turn back here and see whether, following the table, you understand what each key press did and why.
Instead of trying to walk through a screenshot-by-screenshot example of using vi, try typing the following example. Remember to compare what you're typing to the commands in Table 15.9, and watch what happens. Although the finer details are not revealed by this example, you will pick up enough to get you started doing useful work, and to get out of any sticky situations you might find yourself in while editing a file.
Try typing the following exactly as it appears here, and observe what happens. Where a new line appears in the text, press Return. Remember that <esc> is the Escape key.
brezup:ray testing $ vi mynewfile iThis is my new file This is line one of my new file This is a test This is line four of my new file<esc>kddkA This is line three of my new file<esc>khhhhhhhhhhhhhhhhhxxxitwo<esc>:wq!
Your machine should respond
"mynewfile" [New file] 4 lines, 119 characters
although you might not be able to see that because the line flashes off the screen pretty quickly. Now look at what you have:
% cat mynewfile This is my new file This is line two of my new file This is line three of my new file This is line four of my new file
Table 13.11 shows the syntax and common options for the vi (vim) command.
Everything and the Kitchen Sink: emacs
On the other end of the spectrum from vi's odd syntax and tiny footprint is emacs. In certain circles, it is thought that emacs is an acronym for Emacs Makes a Computer Slow because emacs epitomizes the notion of an "everything" package and has the memory footprint to prove it. Including a windowing system, an email-reading client, a news-reading client, a programming language, and an online help database, to name only a few of its features, emacs can almost certainly do anything you want a plain text editor to do.
With today's fast machines and nearly unlimited memory, the major complaints against emacs (it's a gargantuan application with a legendary hunger for computer resources hey it's not all bad people write haiku about it too!) aren't a significant impediment to its use.
From the point of view of the average user, emacs has a much more intuitive interface than vi. You're always in insert mode, just as you're used to in GUI-based word processors. Commands are handled by the use of Control+<key> combinations, instead of the use of a separate mode.
To use emacs, there are some basics that you need to know you can get more information from the online tutorial mentioned at the end of this section. In the following list, whenever you see Ctrl+ preceding a character, it means that you need to hold down the Control key and type that character. Whenever you see Esc- preceding a character, it means to press the Esc key and then the character.
Beyond the Ctrl+ commands available in emacs, an amazingly extensible set of commands also comes into play if you use the Escape (Esc) key. These commands are usually known as emacs meta commands, even though the machines with the meta key from which the commands draw their name have long since faded into history. These commands, even though they're initiated by pressing the Escape key, are usually abbreviated in the documentation with a leading M for meta. The complete set of these commands is the subject of more than one book, and we recommend that you investigate your library or bookstore options if you really want to understand the inner workings. If you're a puzzle solver, some of the interesting items are documented in Table 15.10. A good place to start on meta commands will be with testing out the emacs online help system. Start emacs by simply typing emacs at the prompt. After it has started, press Esc-x and then type help- and press the spacebar. You will be presented with a list of emacs commands starting with help-, including useful things such as help-for-help a good place to start.
Instead of a quick example like the one we used for vi, we suggest you take the emacs tutorial. To enter the emacs tutorial, all you need to do is start emacs and press Ctrl+h t (hold the Ctrl key, press the h key, release them both, and press the t key). If you type a ? after the Ctrl+h instead of the t, you'll see that there is actually a whole world of alternatives to the t (Ctrl+h i is another good place to look). These alternatives give you access to a range of different types of helpful information. For now, take the tutorial. If you're curious, you can probably spend almost eternity exploring the rest of the options available.
Table 13.12 shows a portion of the command documentation table for emacs as well as a listing of some of the help topics detailing a number of the available meta commands. The synopses of the help topic areas should give you an idea of some of the things that you can do, and some of the information that you can look for in the online documentation. A vastly more detailed list of capabilities can be accessed in emacs itself by typing M-x info and selecting the emacs documentation line. It should be clear even from this highly abridged listing that the complete documentation for emacs is voluminous.
Simple and Quick: nano
If you find vi to be unfriendly and emacs to be overwhelming, you might find nano more suitable. The nano editor (the name is derived from Nano's ANOther editor, according to the man page) is a small, menu-driven windowed editing system. It is a pico clone that is distributed under the GNU license. The pico editor was developed as the editor for the pine email package. Starting with Mac OS X 10.4, nano, rather than pico, is included, and pico is just a link to nano. This change is most likely a license issue.
Being a menu-driven system, nano does not lend itself to documentation tables, so instead we will show you some output samples. It is worthwhile, though, to take a look at the man page. nano can be run with some options that you might find useful. For example, the -B flag causes nano to write a backup of your file whose name ends in ~. You can also set nano settings in a ~/.nanorc control file, which is documented in the nanorc man page.
When you run nano, you will get output that looks like this:
GNU nano 1.2.4 New Buffer [ New File ] ^G Get Help ^O WriteOut ^R Read File ^Y Prev Page ^K Cut Text ^C Cur Pos ^X Exit ^J Justify ^W Where Is ^V Next Page ^U UnCut Txt ^T To Spell
As with the pine email reader, there is a menu at the bottom to help you with using the program. After you've started typing something, the [New File] designation in the status line goes away.
When you decide to save your file, press Ctrl+O to save the file. The status line asks for the filename and the menu changes to include options pertinent to saving a file. Here is a sample of the changes you see in the nano interface:
GNU nano 1.2.4 New Buffer Modified Hi there. This is my nano test file. File Name to Write: nano-test ^G Get Help M-D DOS Format M-A Append M-B Backup File ^T To Files M-O Mac Format M-P Prepend ^C Cancel
As you work with nano, you will probably find its help system to be useful. Here is the top-level help system page, which is useful for understanding other nano help pages:
GNU nano 1.2.4 New Buffer nano help text The nano editor is designed to emulate the functionality and ease-of-use of the UW Pico text editor. There are four main sections of the editor: The top line shows the program version, the current filename being edited, and whether or not the file has been modified. Next is the main editor window showing the file being edited. The status line is the third line from the bottom and shows important messages. The bottom two lines show the most commonly used shortcuts in the editor. The notation for shortcuts is as follows: Control-key sequences are notated with a caret (^) symbol and are entered with the Control (Ctrl) key. Escape-key sequences are notated with the Meta (M) symbol and can be entered using either the Esc, Alt or Meta key depending on your keyboard setup. The following keystrokes are available in the main editor window. Alternative keys are shown in parentheses: ^G (F1) Invoke the help menu ^X (F2) Close currently loaded file/Exit from nano ^Y Prev Page ^X Exit ^V Next Page
|< Day Day Up >|