|[Home] [Credit Search] [Category Browser] [Staff Roll Call]||The LINUX.COM Article Archive|
|Originally Published: Friday, 29 October 1999||Author: Stan Shivell|
|Published to: news_learn_support/Support News||Page: 1/1 - [Std View]|
Linux.ie: vi Tutorial 2
Linux.ie has a second part to their vi tutorial showing usage of filters and other vi features.
Firstly, I'd like to thank everybody who mailed me about my last vi tutorial for their kind words - and for asking for more! I also want to clarify that I am not using vi itself but the better known clone called 'vim' which has been ported to a number of different operating systems (Linux, Beos, VMS, DOS, Windows and Amiga to name but a few) and is available for download at the vim website, www.vim.org. I'm mentioning this because there is a chance that I might accidentally describe some vim specific functionality and would greatly appreciate it if corrections were emailed to me. Anyways, time to get on with it...
Lines. There is one mildly annoying thing about vi, which is that for the most part you don't know for certain if one line of text is displayed as just one line or whether it might be so long as to wrap around and be displayed on the screen as being two or more lines. This can be extremely annoying if for example you delete four lines and, due to word wrap, you really only should have deleted two. For this reason it would be rather nice to know where the lines end and how to do something about it. Doing the first is quite simple - type :set list to see where the lines end (which will be indicated with dollar signs, tabs indicated with '^I') and :set nolist to get the display back to normal. Getting vi to do something about it preemptively is rather simple too. All that you need do is type :set wrapmargin=1 to make vi force lines not to wrap, this is a really useful command which probably should be included in your .exrc file. If for some reason you want to undo this, just type :set wrapmargin=0.
Seek and Find. One thing that I was asked to cover was searching for text - and replacing it. On the face of it, searching for text is fairly simple. Press / then type in the text that you want found, pressing return afterwards. To find the next occurrance of the same text just press / and return again. Using / means that the search text will be looked for further into the file that you are editing - if you want vi to search in the other direction then use the question mark (and again you can use ? followed by the return key to search for the previous occurrance of the text you are searching for). If you are alternating between forward and reverse searches you don't have to specify the search text a second time. For example, let's say you were looking for the word 'spam' and you accidentally hit / and the return key before you can read anything else and are shown the next occurrance of 'spam'. You don't have to type ?spam - ? on it's own will suffice. There's one particular disadvantage/annoyance about this though. If you look for the word 'to' vi will find it all over the place as a portion of longer words (try looking for 'to' in "Going towards oblivion tomorrow too!"). There are a number of ways that you can solve this problem. Once you find the first correct occurrance of the word you can use '*' to find the next occurrance of it as a whole word. (* will search forwards, # will search backwards.) What if you are nowhere near the first occurance of the whole word? To solve this you have to wrap the text you are looking for with angle brackets - which you have to 'escape' with '\'. For example, if you want VI to search for the word 'tux' and don't want the word 'tuxedos' to be found, this is what you'd type: /\ followed by the return key. This solution is the better one, mostly because you can use it to search for a phrase or a certain combination of words like "if you". You can search for regular expressions too, just like with sed so if you need to find any number you can do /[0-9] and so on. Regular expressions are much too complex for me to write about in this tutorial, entire books have been written about them. Though of course this mightn't stop me from writing a tutorial on them later on. Don't hold your breath though!