At its most basic level, a filter is a program that accepts input, transforms it and outputs the transformed data. The idea of the filter is closely associated with several ideas that are part of the UNIX operating system: standard input and output, input/output redirection and pipes.
Standard input and output refer to default locations from which a program will take input and to which it will write output. The standard input (STDIN) for a program running interactively at the command line is the keyboard; the standard output (STDOUT) is the terminal screen.
With input/output redirection, a program can take input or send output using a location other than standard input or output—a file, for example. Redirection of STDIN is accomplished using the < symbol, redirection of STDOUT by >. For example,
ls > list
redirects the output of the ls command, which would normally go to the screen, into a file called list. Similarly,
cat < listredirects the input for cat, which in the absence of a file name would be expected from the keyboard, to come from the file list--so we output the contents of that file to the screen.
Pipes are a means of connecting programs together through I/O redirection. The symbol for pipe is |. For example,
ls | less
is a common way of comfortably viewing the output from a directory listing where there are more files than will fit on the screen.
Simple programs provided as standard with your Linux system can be enhanced by using them as filters for other similar programs. I'll also show how simple programs of your own can be built to meet custom filtering needs.
One program I don't look at in this article is Perl. Perl is a programming language in its own right, and filters are language-independent.
The program grep, “Get Regular Expression and Print”, is a good place to begin. (See “Take Command: grep” by Jan Rooijackers, March 1999.) The principle of grep is quite simple: search the input for a pattern, then output the pattern. For example,
grep 'Linus Torvalds' *
searches all files in the current directory for Linus' name.
Various command-line switches may be used to modify grep's behaviour. For example, if we aren't sure about case, we can write
grep -y 'linus torvalds' *
The -y switch tells grep to match without considering case. If you use any upper-case letters in the pattern, however, they will still match only upper-case. (This is broken in GNU grep, which simply ignores case when given the -y switch—that's what the -i switch does).
With just this bit of information about grep, it is easy to construct a practical application. For example, you could store name and address details in a file to create a searchable address book.
Sometimes, basic grep won't do. For instance, suppose we want to find all occurrences of a text string which could possibly be a reference to Linus. Clearly, searching for 'Linus Torvalds' is not enough—that won't find just Linus or Torvalds. We need some way of saying, “This or this or this”. Here is where egrep (extended grep) comes in. This handy program modifies standard grep to provide just such a conditional syntax by using the | character to denote “or”.
egrep 'Linus Torvalds|L\. Torvalds|Mr\. Torvalds' *
will now find most ways of naming the inventor of Linux. Note the backslash to “escape” the period. Since it is a special character in regular expressions, we must tell egrep not to interpret it as a “magic” character.
tr is perhaps the epitome of filters. (See “Take Command: A Little Devil Called tr” by Hans de Vreught, September, 1998.) Short for translate, tr basically does what its full name suggests: it changes a given character or set of characters to another character or set of characters. This is done by mapping input characters to output characters. An example will make this clear:
tr A-Z a-z
changes upper-case letters to lower-case. A-Z is shorthand for “all the letters from A to Z”.
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!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
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