bash脚本创建变量_创建一个Bash脚本模板

bash脚本创建变量

在本系列的第一篇文章中，您创建了一个很小的单行Bash脚本，并探讨了创建Shell脚本的原因，以及为什么它们是系统管理员而非编译程序最有效的选择。

在第二篇文章中，您将开始创建一个Bash脚本模板，该模板可用作其他Bash脚本的起点。该模板最终将包含一个帮助工具，一个许可声明，一些简单的功能，以及一些处理这些选项的逻辑，以及基于该模板的脚本可能需要的其他逻辑。

为什么要创建模板？

懒惰的系统管理员。”模板中包含了在所有脚本所需的基本组件。它节省相比，添加这些成分的每一个新的脚本时间，可以很容易地开始一个新的脚本。

尽管将一些命令行Bash语句放到一个文件中并使其可执行是很诱人的，但从长远来看，这可能会适得其反。精心编写且备受好评的Bash程序具有帮助功能以及接受命令行选项的能力，为维护该程序（包括您编写和维护的程序）的系统管理员提供了一个很好的起点。

要求

您应该始终为所做的每个项目创建一组需求。即使它是仅包含两个或三个项目的简单列表，也包括脚本。我参与了很多项目，这些项目要么完全失败，要么无法满足客户的需求，通常是由于缺少需求声明或撰写不当的缘故。

这个Bash模板的要求非常简单：

创建一个可用作将来Bash编程项目起点的模板。
该模板应遵循标准的Bash编程惯例。
它必须包括：
- 标题部分，可用于描述程序的功能和变更日志
- 许可声明
- 功能部分
- 帮助功能
- 测试程序用户是否为root的功能
- 一种评估命令行选项的方法

基本结构

一个基本的Bash脚本包括三个部分。 Bash无法描绘部分，但是部分之间的边界是隐式的。

所有脚本必须以shebang（＃！）开头，并且必须是任何Bash程序的第一行。
功能部分必须在shebang之后和程序主体之前开始。作为记录所有内容的一部分，我在每个功能前加了一条注释，并简要说明了它的作用。我还将在函数内添加注释以进一步阐述。简短的简单程序可能不需要功能。
该程序的主要部分位于功能部分之后。这可以是单个Bash语句或数千行代码。我的一个程序有200多行代码，还不包括注释。该程序有600多个注释行。

仅此而已-任何Bash程序的结构只有三个部分。

主要评论

由于各种原因，我总是添加更多内容。首先，我在shebang之后立即添加了几部分评论。这些注释部分是可选的，但是我发现它们很有帮助。

第一个注释部分是程序名称和描述以及更改历史记录。我在IBM工作时就学习了这种格式，它提供了一种记录程序的长期开发以及应用到该程序的修复程序的方法。这是记录程序的重要起点。

第二个评论部分是版权和许可声明。我使用GPLv2，这似乎是根据GPLv2许可的程序的标准声明。如果您使用其他开源许可证，那很好，但是我建议在代码中添加一个明确的声明，以消除有关许可证的任何可能的混淆。 Scott Peterson的文章源代码是许可证，可以帮助解释其背后的原因。

所以现在脚本看起来像这样：

#!/bin/bash

        ################################################################################

        #                              scriptTemplate                                  #

        #                                                                              #

        # Use this template as the beginning of a new program. Place a short           #

        # description of the script here.                                              #

        #                                                                              #

        # Change History                                                               #

        # 11/11/2019  David Both    Original code. This is a template for creating     #

        #                           new Bash shell scripts.                            #

        #                           Add new history entries as needed.                 #

        #                                                                              #

        #                                                                              #

        ################################################################################

        ################################################################################

        ################################################################################

        #                                                                              #

        #  Copyright (C) 2007, 2019 David Both                                         #

        #  LinuxGeek46@both.org                                                        #

        #                                                                              #

        #  This program is free software; you can redistribute it and/or modify        #

        #  it under the terms of the GNU General Public License as published by        #

        #  the Free Software Foundation; either version 2 of the License, or           #

        #  (at your option) any later version.                                         #

        #                                                                              #

        #  This program is distributed in the hope that it will be useful,             #

        #  but WITHOUT ANY WARRANTY; without even the implied warranty of              #

        #  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the               #

        #  GNU General Public License for more details.                                #

        #                                                                              #

        #  You should have received a copy of the GNU General Public License           #

        #  along with this program; if not, write to the Free Software                 #

        #  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA   #

        #                                                                              #

        ################################################################################

        ################################################################################

        ################################################################################

echo "hello world!"

运行修改后的程序，以验证它仍然可以正常运行。

`关于测试`

现在是谈论测试的好时机。

“ 总会有一个错误。” —卢巴尔斯基的控制论昆虫学定律

卢巴尔斯基（不管是谁）是正确的。您永远找不到代码中的所有错误。对于我发现的每个错误，似乎总是会出现另一个错误，通常是在非常不合时宜的时候。

测试不仅涉及程序。这也与验证实际上应该解决的问题有关-无论是由硬件，软件还是用户发现破坏事物的看似无穷无尽的方式引起的。同样重要的是，测试还涉及确保代码易于使用并且界面对用户有意义。

在编写和测试shell脚本时遵循明确定义的过程可以有助于获得一致且高质量的结果。我的过程很简单：

创建一个简单的测试计划。
从开发之初就开始测试。
代码完成后执行最终测试。
投入生产并进行更多测试。

`测试计划`

测试计划有很多不同的格式。从头到尾，我一直在全力以赴。在纸上写下的一些笔记；以及一整套复杂的表格，需要对每个测试进行完整的描述，将测试的功能代码，测试将完成什么以及输入和结果应该是什么。

以曾经（但现在不是）测试员的系统管理员的身份，我尝试走中间立场。至少有一个简短的书面测试计划可以确保从一个测试到下一个测试的一致性。您需要多少细节取决于开发和测试功能的形式。

我使用Google发现的示例测试计划文档非常复杂，并且适用于具有非常正式的开发和测试流程的大型组织。尽管这些测试计划对职称中带有“测试”的人而言是不错的选择，但它们不适用于系统管理员更加混乱且依赖时间的工作条件。与工作的大多数其他方面一样，系统管理员必须具有创造力。因此，这里是要考虑的简短清单，包括在您的测试计划中。对其进行修改以适合您的需求：

被测试软件的名称和简短描述
对要测试的软件功能的描述
每次测试的开始条件
每次测试应遵循的功能
每个测试的预期结果的描述
专为测试阴性结果而设计的特定测试
测试程序如何处理意外输入
明确说明每项测试通过或不通过的原因
模糊测试，如下所述

此列表应为您提供一些有关创建测试计划的想法。大多数系统管理员应该保持它简单和相当非正式。

`尽早测试-经常测试`

我总是在完成第一部分可执行文件后立即开始测试Shell脚本。无论我编写的是简短的命令行程序还是可执行文件的脚本，都是如此。

我通常开始使用Shell脚本模板创建新程序。我为帮助功能编写代码并进行测试。这通常是该过程的一个微不足道的部分，但是它可以帮助我入门，并确保模板中的内容在一开始就可以正常工作。此时，很容易解决脚本模板部分的问题或对其进行修改以满足标准模板所没有的需求。

模板和帮助功能正常工作后，我将继续通过添加注释来记录程序的步骤，以满足程序规范的要求，从而创建程序主体。现在，我开始添加代码以满足每个注释中所述的要求。此代码可能需要添加在模板的该部分中初始化的变量，而该部分现在已成为shell脚本。

在这里，测试不仅仅是输入数据和验证结果。这需要一些额外的工作。有时，我添加一条命令，该命令仅打印我刚刚编写的代码的中间结果并进行验证。对于更复杂的脚本，我为“测试模式”添加了-t选项。在这种情况下，仅在命令行上输入-t选项时才执行内部测试代码。

`最终测试`

代码完成后，我将使用已知的输入生成特定的输出，对所有功能部件进行完整的测试。我还测试了一些随机输入，以查看程序是否可以处理意外的输入。

最终测试旨在验证程序是否基本按预期运行。最终测试的很大一部分是确保在开发周期中较早运行的功能不会被在该周期中较晚添加或更改的代码所破坏。

如果您在向脚本添加新代码时一直在对其进行测试，则您可能会认为在最终测试期间应该不会感到意外。错误！在最终测试期间总会有惊喜。总是。期待那些惊喜，并准备花费时间修复它们。如果在最终测试期间从未发现任何错误，那么进行最终测试就没有意义了吗？

`生产测试`

啊，什么？

“直到程序生产至少六个月，才会发现最有害的错误。” -Troutman的编程假设

是的，现在认为在生产中进行测试是正常且可取的。我自己曾经是测试人员，这似乎是合理的。你说：“但是等等！这很危险。” 我的经验是，它并没有比在专用测试环境中进行广泛而严格的测试更加危险。在某些情况下，别无选择，因为没有测试环境，只有生产。

系统管理员对于在生产环境中测试新的或修订的脚本并不陌生。每当将脚本移入生产环境时，这便是最终的测试。生产环境是该测试中最关键的部分。测试人员无法在测试环境中实现的梦想可以完全复制真实的生产环境。

据称在生产中进行测试的新实践只是对系统管理员一直以来所知的认可。最好的测试是生产-只要它不是唯一的测试即可。

`模糊测试`

这是最初引起我翻白眼的那些流行语中的另一个。它的本质含义很简单：让某人敲击键直到发生某种事情，然后查看程序如何处理它。但是，实际上还不止如此。

模糊测试有点像我儿子在不到一分钟的时间内用随机输入破解游戏代码的时间。那几乎结束了我为他写游戏的尝试。

大多数测试计划都利用非常具体的输入来生成特定的结果或输出。不管测试将成功定义为正面还是负面，都将对其进行控制，并指定和预期输入和结果，例如针对特定故障模式的特定错误消息。

模糊测试涉及在测试的各个方面处理随机性，例如开始条件，非常随机和意外的输入，所选选项的随机组合，低内存，与其他程序竞争的CPU数量高，被测程序的多个实例，以及您认为可以应用于测试的任何其他随机条件。

我从一开始就尝试进行一些模糊测试。如果Bash脚本在其早期阶段不能处理明显的随机性，那么随着添加更多代码，它不太可能变得更好。这是抓住这些问题并修复它们的好时机，而代码则相对简单。在每个阶段进行一些模糊测试对于在问题被更多代码掩盖之前找出问题也很有用。

代码完成后，我喜欢做一些更广泛的模糊测试。总是做一些模糊测试。我当然对某些结果感到惊讶。测试期望的事情很容易，但是用户通常不会使用脚本来完成期望的事情。

`即将来临的景点预览`

本文在创建模板方面取得了一些成就，但主要讨论了测试。这是因为测试是创建任何类型程序的关键部分。在本系列的下一篇文章中，您将在Bash脚本模板中添加一个基本的Help函数以及一些代码来检测选项-h并对其执行操作。

`资源资源`

如何使用Bash编程：语法和工具
如何使用Bash编程：逻辑运算符和Shell扩展
如何使用Bash编程：循环

本系列文章部分基于David Both的Linux自学课程（共三部分）的第2卷第10章，该课程使用和管理Linux —从零到SysAdmin 。

翻译自: https://opensource.com/article/19/12/bash-script-template

bash脚本创建变量