Nine major Inspirations from good UNIX tools

We use various tools developed by our predecessors every day. A good tool can be seamlessly integrated into your work environment, while a poor tool often requires extra effort to integrate into your work environment. (Note: The difference here refers to user experience issues, but these tools are still useful ). As engineers, we always need to develop some tools for ourselves or for others. This article by Marius ERIKSEN (http://monkey.org /~ Marius/unix-tools-hints.html) talked about the things to be aware of when designing UNIX tools. It should be noted that this article describes the suggestions for developing UNIX tools, mainly to make them well integrated with the classic UNIX tools, therefore, the suggestions may not apply to other scenarios. This article briefly summarizes the Marius article to help readers.

1. read data from the standard input (stdin) and output the result to the standard output (stdout ).
In other words, your tool should be a filter so that it can be easily integrated into the shell pipeline to work with many UNIX tools.

2. It is best not to include headers or other decorative outputs in the output results
If the person using your tool needs to parse the output result of the tool, too many of the output results will make the parsing complicated.

3. output results should be easily parsed
Each record in the result should preferably be a single line and output in plain text. The columns in each record should be separated by spaces or tabs (please do not output in JSON format ). Because the classic UNIX tools, such as sort, grep, and SED, assume that the input is in this format.

4. Regard the output of the tool as the API of the tool.
For API, it is very important to maintain its stability. If the output format of your tool changes, other tools that depend on you may be released.

5. output the diagnostic information to the standard error (stderr)
The diagnostic information includes the progress information, debugging information, logs, errors, and usage information, which is not the main output information of your tool. If the diagnostic information and data are mixed together, the output results of the tool are difficult to parse. Another advantage of outputting diagnostic information to stderr is that when you filter or redirect data, the diagnostic information will still be completely output to the screen.

6. Mark errors with exit Status Codes
If your tool fails to run, set the exit status code to a non-0 value. This allows your tool to be well integrated with other scripts. I think this is not controversial.

VII. Try to include complete information in the output content
The output content may inevitably contain context or environment information, such as the machine name and file path. The output of good tools should provide complete information as much as possible, such as absolute paths and FQDN. In this way, only a small amount of context information is needed to understand the output content. For example, if the relative path of the file is output, you need to know what the current working directory is to know where the corresponding file is.

8. Avoid excessive useless diagnostic information
Do not output too much diagnostic information normally. If this is the case, output the diagnostic information to stderr and put it in verbose mode. The verbose mode is disabled by default.

9. Avoid User Interaction
Good tools should avoid user interaction, which enables the tool to be scheduled by cron or executed on a remote machine. Tools that require interaction are very difficult to integrate with other tools. If you want to provide the interactive mode, you must also provide the silent mode.

In scenarios where user interaction is required, the user may be asked to confirm a dangerous operation. In this case, the user can specify a specific parameter, for example, you can use git branch-D to delete a branch in git. When there is a commit on branch that is not merged, you need to use git branch-D to force the branch to be deleted.

As you can see, the above suggestions mainly focus on how to integrate tools with other tools and how to make the output of tools better parsed. If you consider these suggestions when developing tools, your tools will be better.

If you want to learn the latest skills, please pay attention to the public number "Engineer's affairs"

Nine major Inspirations from good UNIX tools