Vim for C Programmers
Vim is an extremely powerful editor with a user interface based on Bill Joy's almost 30-year-old vi, but with many new features. The features that make Vim so versatile also sometimes makes it intimidating for beginners. This article attempts to level the learning curve with a specific focus on C programming.
A typical programmer's routine involves compiling and editing programs until the testing proves that the program correctly does the job it is supposed to do. Any mechanism that reduces the rigor of this cycle obviously makes any programmer's life easier. Vim does exactly that by integrating make with Vim in such a way that you don't have to leave the editor to compile and test the program. Running :make from inside of Vim does the job for you, provided a makefile is in the current directory.
You can change the directory from inside of Vim by running :cd. To verify where you are, use :pwd. In case you are using FreeBSD and want to invoke gmake instead of make from the command line, all you have to do is enter :set makeprg=gmake. Now say you want to give some parameters to make. If, for instance, you want to give CC=gcc296:
:set makeprg=gmake\ \CC=gcc296
does the job.
Now comes the job of inspecting the errors, jumping to the appropriate line number in the source file and fixing them. If you want to display the line numbers in the source file, :se nu turns on this option, and :se nonu disables line number display.
Once you compile, Vim automatically takes you to the first line that is causing the error. To go to the next error; use :cn to take you to the next line number causing the error. :cfirst and :clast take you to the first error and the last error, respectively. One you have fixed the errors, you can compile again. If you want to inspect the error list again, :clist displays it. Convenient, isn't it?
If you want to read some other source file, say foo.c, while fixing a particular error, simply type :e foo.c.
One shortcut provided by Vim to avoid typing too much to switch back to the previous file is to type :e # instead of typing the full path of the file. If you want to see all of the files you have opened in Vim at any point in time, you can use :ls or :buffers.
If you have a situation in which you have opened too many files and you want to close some of them, you can issue :ls. It should display something like this:
2 # "newcachain.c" line 5 3 %a "cachain.c" line 1
If you want to close newcachain.c, :bd 2 or :bd newcachain.c does the job.
While browsing C code, you may have situations in which you want to skip multiple functions fast. You can use the ]] key combination for that while in command mode. If you want to browse backward in the file, [[ can be used.
You also can use marks to bookmark certain cursor positions. You can use any lowercase alphabet character as a mark. For instance, say you want to mark line number 256 of the source and call it b. Simply go to that line, :256, and type mb in command mode. Vim never echos what you type in command mode but silently executes the commands for you.
If you want to go to the previous position, '' (two single-quotation marks) takes you there. Typing 'a takes you to mark a and so on.
Especially when editing Makefiles, you may want to figure out which of the white spaces are tabs. You can type :se list, and whatever is displayed as ^I in blue are tabs. Another way to do that is to use /\t. This highlights the tabs in yellow.
Global searches and replaces are common tasks for programmers, and Vim provides good support for both. Simply type / in command mode, and you are taken to the searched keyword. If you prefer incremental searches, à lá emacs, you can specify :se incsearch before you search. When you want to disable it, type :se nois.
Search and replace is a powerful tool in Vim. You can execute it only on a region that you selected using the v command, only between certain line numbers or only in rectangular regions selected by using Ctrl-V command.
Once you select your region or line number ranges, for example using :24,56 to select lines 24–56 (both inclusive), or just select your region and type : :<','> appears. Now type s/foo/bar to replace all occurrences of the string foo with bar.
But, this command replaces only one instance per line. If you want to do this for multiple occurrences per line, type s/foo/bar/g. If you want to replace only some occurrences, you can use the “confirm” option with s/foo/bag/gc.
Sometimes the string contains characters that appear as a substring of other keywords. For instance, say you want to replace the variable “in” and not the “in” in inta. To search for whole words, type /\<in\>/.
Most commonly, you will want to do a global replace, which is every instance in a given file. You can do that by using either :1,$s/foo/bar/g or :%s/foo/bar/g. If you then want to replace this in all the files you have open, you can enter :bufdo %s/foo/bar/g.
Another way of searching is by going to the keyword and typing * in command mode. The keyboard now will be highlighted wherever it occurs in the file. Searching backward is simple too; type ? instead of / while searching.
Once the searching is over, Vim remembers it, so the next time you search for the same keyword, you have to type only / or ?, instead of typing the whole text.
One side effect of searching is that it stays highlighted. This can be a distraction while editing programs. Turn highlighting off by typing :se nohlsearch, :nohlsearch or :nohl
You always can use the Tab key to complete Vim commands you give with a colon. For instance, you can type :nohl<Tab>, and Vim completes it for you. This is applicable generically, and you can press Tab to cycle through Vim's commands until Vim finds a unique match.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Tech Tip: Really Simple HTTP Server with Python
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide