shell 脚本有很多命令行参数是不是很奇怪答案

【问题标题】：Is it bizarre to have many command line arguments to a shell scriptshell 脚本有很多命令行参数是不是很奇怪
【发布时间】：2018-06-02 04:05:48
【问题描述】：

在我们的环境中，我们有近 30 个应用程序和 5 个环境。由于时间线问题，我们创建了5[env]*3[three scripts per env]*30[num of applications]。它是 450 个文件。

我们了解到我们不必要地复制了代码。如果我们必须更改环境的某些挂载点位置，则必须在整个应用程序中进行更改。

所以我设计了一种方法，其中包含 3[所有应用程序的文件] + 2[具有应用程序特定方法的文件]。

它工作正常。但这里的问题是我们需要将 7 个参数传递给这三个脚本。

所以有一种说法是脚本很奇怪而且很麻烦。我想知道 bash 脚本的命令行参数的建议数量是多少。

我找不到任何与此相关的文档。但我提到了this。这并不能说服我。

有什么建议吗？我真的需要为了 7 个参数而重新考虑设计吗？

注意：我做到了。我现在有一个包含 3-5 个参数的解决方案。但我想知道推荐的参数数量。

【问题讨论】：

常用终端命令有时会难以置信。有七个参数不会比我在grep 和sed 中使用的一些常用命令长。但是，多长多长取决于个人喜好。
参数的数量无关紧要。给同事一个手册页，看看他们是否可以轻松构建他们想要的命令。如果像cp 一样，您只列出单个文件，则可以接受数千个文件。如果像ffmpeg 一样，大多数选项都有默认值，并且您只需指定要以任何顺序影响编码过程的哪些部分，那么有几十个就可以了。如果像clang 这样的选项可以相互依赖并且文件的顺序对符号解析很重要，那么这可能是一个很大的麻烦。
感谢@thatotherguy 和 ifconfig 我从您提到的示例中了解到。
再添加一个示例，您会看到对find 命令的非常冗长的调用。

标签： bash shell

【解决方案1】：

如果脚本需要以特定顺序排列的七个特定、不同的参数，那么——是的，我认为这太多了。区别

foo.sh fred wilma pebbles dino barney betty bamm-bamm

和

foo.sh fred wilma pebbles barney betty bamm-bamm dino

太微妙了；对编写脚本的人最有意义的参数顺序与对每个使用它的人最有意义的顺序不同。

但是，在许多情况下，您可以通过“命名”参数来改善这种情况（而不用担心顺序）：

foo.sh \
    --father-1=fred --mother-1=wilma --child-1=pebbles --pet-1=dino \
    --father-2=barney --mother-2=betty --child-2=bamm-bamm

更容易自信地使用（尤其是当参数丢失或出现两次时脚本给出明确的错误消息时）。

【讨论】：

可以使用getopt来帮助解析arg。在您的系统上查找示例文件以获得帮助：locate getopt-parse.bash。 bash 内置 getopts 更易于使用，但它只处理 1 个字母的选项名称。

【解决方案2】：

您可以编写一个主脚本并使用其他脚本调用该主脚本。

主脚本可以处理包装器中设计的参数。当你需要从 env test、task run、application hello 和命令行的其他选项调用它时，使用像这个文件 hello.sh 的包装器

#!/bin/bash
# example calling master.sh function doit()
source master.sh
env=test
application=hello # or application_sh=${0##*/} and remove .sh later
check_input # call some application specific function checking the parameters
doit "${env}" "${application}" $*

也许将这些包装器收集到子文件夹中。

/prod
/prod/hello
/prod/run
/prod/monitor
/prod/.../application1
/prod/.../application2
/prod/.../application3
/prod/monitor/application30
/accp/...
/test/...
/dev1/...
/dev2/...

如果你能以某种方式扣除环境，那就更容易了。

case ${hostname} in
   myprod) env=prod;;
   ..) env=something;;
   *) env=develop;;
esac
case ${mode} in
email|sms) 
  application=monitor;;
uk|us|nl|de) 
  application=hello;;
single_user|multithreaded) 
  application=run;;
junit_test) 
  application=run
  env=development;; # overrule env by hostname
esac

【讨论】：