我基本上同意之前的答案,但有另一个重要方面:
可用性。
例如,在
git
中,您可以创建一个存储库,并将
.git目录放在外部。要指定它,可以使用命令行参数
--git-dir
或环境变量
GIT_DIR
。
当然,如果你将当前目录更改为另一个存储库或在脚本中继承环境变量,就会出现错误。但是,如果您需要在一个终端会话的分离存储库中键入多个
git
命令,则这非常方便:您不需要重复
git-dir
参数。
另一个例子是
GIT_AUTHOR_NAME
。似乎它甚至没有一个命令行伙伴(但是,
git commit
有一个
--author
参数)。
GIT_AUTHOR_NAME
覆盖了
user.name和
author.name配置设置。
总的来说,在UNIX上使用命令行或环境参数同样简单:可以使用命令行参数。
$ command --arg=myarg
或者在一行中使用环境变量:
$ ARG=myarg command
在alias
中,捕获命令行参数也很容易:
alias cfg='git --git-dir=$HOME/.cfg/ --work-tree=$HOME'
alias grep='grep --color=auto'
一般而言,大多数参数都是通过命令行传递的。我同意之前的答案,这种方式更加实用和直接,脚本中的环境变量就像程序中的全局变量一样。
GNU libc 表示:
argv 机制通常用于传递特定于被调用程序的命令行参数。另一方面,环境跟踪由许多程序共享、不经常更改且较少使用的信息。
除了关于环境变量危险性的说法外,它们还有很好的用例。
GNU make 对环境变量有非常灵活的处理方式(因此与 shell 非常集成):
make 启动时看到的每个环境变量都会转换为具有相同名称和值的 make 变量。但是,在 makefile 中或使用命令参数进行显式赋值会覆盖环境变量。(-- 并且有一个选项来更改此行为)...
因此,通过在您的环境中设置变量CFLAGS,您可以使大多数makefile中的所有C编译都使用您喜欢的编译器开关。对于具有标准或常规含义的变量来说,这是安全的,因为您知道没有任何makefile会将它们用于其他事情。
最后,我要强调的是,对于一个程序来说,最重要的不是程序员,而是用户体验。也许您已经将其包含在设计方面了,但内部和外部设计是非常不同的实体。
关于编程方面,我想说几句。您没有写明使用哪种语言,但我们可以想象您的工具允许您进行最佳的参数解析。在Python中,我使用
argparse,它非常灵活且功能丰富。要获取解析的参数,可以使用类似以下的命令:
args = parser.parse_args()
args可以进一步分解为已解析的参数(例如
args.my_option),但我也可以将它们作为整体传递给我的函数。如果您的语言允许,这种解决方案绝对不会“难以维护大量参数”。实际上,如果您有许多参数,并且它们在参数解析期间未被使用,请将它们传递到容器中,以避免代码重复(这会导致不灵活性)。
最后的评论是,解析环境变量比命令行参数容易得多。环境变量只是一对
VARIABLE=value
。命令行参数可能更加复杂:它们可以是位置参数或关键字参数,也可以是子命令(例如
git push
)。它们可以捕获零个或多个值(请回想一下命令
echo
和像
-vvv
这样的标志)。有关更多示例,请参见
argparse。
还有一件事。你对内存的担忧有点令人不安。不要编写泛泛而谈的程序。库应该是灵活的,但是一个好的程序应该没有任何参数就可以使用。如果需要传递大量内容,这可能是数据,而不是参数。如何将数据读入程序是一个更为普遍的问题,没有适用于所有情况的单一解决方案。