Shell software Tool Design principles _ turn

With the passage of time, people developed a set of principles for designing and writing software tools. In the program used to solve the problem, you will see examples of how these principles are applied. Good software tools should have the following features:
One good thing at a time
In many ways, this is the most important principle. If the program does only one thing, it is much easier to design, write, debug, maintain, and generate files. For example, you should not expect to use it to perform arithmetic operations in order to find a file with a style-compliant grep program.
The result of this principle is that it will continue to produce smaller, more specialized programs, like the professional Carpenter's toolbox, which will always have a set of tools designed specifically for specific purposes.
handle text lines, do not process binary data
The text line is a common format for UNIX. When you write your own tool program, you will find that the data file containing the lines of text is well handled, you can edit it with any handy text editor, or you can let the data transfer between the network and various machine architectures. Using a text file is more useful for combining any custom tool with an existing UNIX program.
using regular Expressions
Regular expressions (regular expression) are a strong text processing mechanism. Understanding its mode of operation and using it can moderately simplify the task of writing command scripts (script).
In addition, although regular expressions have been changing over the years on the Tools and UNIX versions, the POSIX standard provides only two regular expressions. You can use the standard library program to perform pattern matching work. This makes it possible to write a dedicated tool program for regular expressions consistent with grep (POSIX calls basic regular expressions, Regular Expressions,bre), or for a regular expression consistent with egrep (POSIX is called an extended regular expression, Extended Regular expressions,ere).
use standard input and output by default
In the case where the file name is not explicitly specified, the program reads the data from its standard input by default, writes the data to its standard output, and the error message is routed to the standard error output (This section is discussed in Chapter 2nd). Writing programs in this way makes it easy to make them data filters (filter), for example, the larger the component size, the more complex pipelines (pipeline) or scripts are required to handle.
Avoid chatter
The process of executing software tools should not be like "chat" (chatty). Do not put information such as "Start processing" (starting processing), "nearing completion" (almost done) or "processing complete" (finished processing) into the standard output of the program (at least this should not be the default state).
When you intentionally string some tools into a pipeline, for example:
1.tool_1 datafile tool_2 tool_3 tool_4 resultfile
If each tool generates information such as "in Process" (yes I ' m working) and sent to the pipeline, then do not expect the execution result to be as expected. In addition, if each tool transmits its own information to the standard error output, the entire screen will be filled with useless process information. In the World of tool programs, no news is good news.
This principle has a different meaning in fact. In general, UNIX utility programs always follow the design philosophy of "What you call it to do, what you get". They don't ask, "Are you sure?" "(Is you sure) this problem, when the user types RM Somefile,unix The designer will assume that the user knows what he is doing, and then there is no doubt that RM deletes the file to be deleted (Note 5).
the output format must match the acceptable input format
The resulting output should follow the same rules as the input, which is considered by a professional tool program to follow the input data in a certain format, such as after the header row followed by a row of data, or using a field delimiter on the row. The advantage of this is that it is easy to hand over the results of one program to another process.
For example, the NETPBM assembly (note 5) is used to process an image file saved in portable BitMap (PBM) format (note 6). These files contain bitmapped images and are drawn using well-defined formats. Each tool that reads the PBM file will first process the image in a file in some format, and then write back to the file in PBM format. In this way, you can combine a simple pipeline to perform complex image processing, such as scaling the image first, then rotating the direction, and then dimming the color.
Let the tool do the difficult part
Although UNIX programs do not exactly match your needs, the existing tools may already be able to do 90% of your work for you. Next, if you need to, you can write a function-specific small program to complete the rest of the work. This has saved you a lot of work compared to solving each problem from scratch.
before you build a specific tool, think about
As mentioned earlier, if there are no required programs in the existing system, it can take some time to build the tools needed to meet the requirements. However, before you start writing a program that solves the problem, stop and think for a few minutes. Do you have to do what other people have to do? Is this particular job likely to be a special case of a general problem? If so, write a program for general questions. Of course, when you do this, you should follow the principles mentioned above, whether in the design or writing of the program.

Excerpt from: "Shell Scripting Learning Guide"

By studying this book, you can not only understand the Unix toolset, but also absorb the central idea of UNIX and the Principles of software tool design.

Shell software Tool Design principles _ turn