在我们的环境中,我们有近30个应用程序和5个环境。由于时间轴问题,我们创建了5[env]*3[three scripts per env]*30[num of applications]
。这是450个文件。
我们理解我们不必要地复制了代码。如果我们必须为环境更改某些安装点位置,则必须在整个应用程序中进行更改。
所以我设计了一个方法,包含3个[所有应用程序的文件] + 2个[具有应用程序特定方法的文件]。
工作正常。但问题是我们需要将7个参数传递给这三个脚本。
所以有一种说法认为剧本很奇怪而且很麻烦。我想知道bash脚本的命令行参数的建议数量是多少。
我无法找到与此相关的任何文档。但我提到this。它并没有让我信服。
有什么建议吗?我是否需要仅仅为了7个参数而重新考虑设计。
注意:我做到了。我现在有3-5个参数的解决方案。但我想知道建议的参数数量。
答案 0 :(得分:3)
如果脚本需要特定顺序的七个特定的,不同的参数,那么 - 是的,我认为这太多了。
之间的区别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
更容易自信地使用(特别是如果脚本在参数丢失或出现两次时发出明确的错误消息)。
答案 1 :(得分:0)
您可以编写一个主脚本并使用调用该脚本的其他脚本。
主脚本可以处理包装器中设计的参数。
当您需要从env test
,任务run
,应用程序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