Fatal编程技术网
  • command-line/
  • Command line 参数传递策略-环境变量与命令行

Command line 参数传递策略-环境变量与命令行

command-line process

Command line 参数传递策略-环境变量与命令行,command-line,process,environment-variables,argument-passing,spawn,Command Line,Process,Environment Variables,Argument Passing,Spawn,我们开发人员编写的大多数应用程序都需要在启动时进行外部参数化。我们传递文件路径、管道名称、TCP/IP地址等。到目前为止，我一直在使用命令行将这些信息传递给正在启动的应用程序。我必须在main中解析命令行，并将参数指向需要它们的地方，这当然是一个很好的设计，但对于大量参数来说很难维护。最近我决定使用环境变量机制。它们是全局的，可以从任何地方访问，从体系结构的角度来看，这不太优雅，但限制了代码的数量 这是我对这两种策略的第一印象（可能很肤浅），但我想听听更有经验的开发人员的意见--使用环境变量和命

我们开发人员编写的大多数应用程序都需要在启动时进行外部参数化。我们传递文件路径、管道名称、TCP/IP地址等。到目前为止，我一直在使用命令行将这些信息传递给正在启动的应用程序。我必须在
main
中解析命令行，并将参数指向需要它们的地方，这当然是一个很好的设计，但对于大量参数来说很难维护。最近我决定使用环境变量机制。它们是全局的，可以从任何地方访问，从体系结构的角度来看，这不太优雅，但限制了代码的数量

这是我对这两种策略的第一印象（可能很肤浅），但我想听听更有经验的开发人员的意见--使用环境变量和命令行参数将参数传递给流程有什么起伏？我想考虑以下事项：

  • 设计质量（灵活性/可维护性）
  • 内存限制
  • 解决方案可移植性
    备注：

    公元1年。这是我感兴趣的主要方面

    公元2年。这有点务实。我知道Windows目前存在一些限制（命令行和环境块都超过32kB）。我想这不是一个问题，因为如果需要的话，您应该使用一个文件来传递大量的参数

    公元3年。我对Unix几乎一无所知，所以我不确定这两种策略是否像在Windows上一样可用。请详细说明一下

    您应该使用模式提取读取参数。创建一个名为
    ConfigurationSource
    的抽象，它具有
    readConfig（key）->value
    方法（或返回一些
    Configuration
    object/structure），实现如下：

    • CommandLineConfigurationSource
    • EnvironmentVariableConfigurationSource
    • WindowsFileConfigurationSource
      -从
      C:/Document and settings…
    • WindowsRegistryConfigurationSource
    • NetworkConfigrationSource
    • UnixFileConfigurationSource
      -从配置文件从
      /home/user/…
    • DefaultConfigurationSource
      -默认值
    您还可以使用模式在各种配置中链接源，例如：若未提供命令行参数，请尝试环境变量，若其他所有操作都失败，则返回defauls

    公元1年。这种方法不仅允许您抽象读取配置，而且可以轻松地更改底层机制，而不会对客户端代码产生任何影响。您还可以一次使用多个源，从不同的源返回或收集配置

    公元2年。只要选择合适的实现即可。当然，某些配置条目不适合命令行参数中的实例

    公元3年。如果某些实现不可移植，则有两个，一个在不适合给定系统时被忽略/跳过。

    1）我建议尽量避免环境变量

    环境变量的优点

    • 易于使用，因为从任何地方都可以看到它们。如果许多独立的程序需要一条信息，这种方法就方便多了
    环境变量的缺点

    • 很难正确使用，因为它们在任何地方都可见（可删除、可设置）。如果我安装了一个依赖于环境变量的新程序，他们会践踏我现有的程序吗？昨天我胡闹的时候，是不是不小心把我的环境变量搞砸了
    我的意见

    • 对于那些对于程序的每次单独调用最可能不同的参数，使用命令行参数（例如，对于计算n的程序，使用n！）
    • 将配置文件用于用户可能希望更改但不经常更改的参数（即，当窗口弹出时显示大小）
    • 节约使用环境变量——最好仅用于预期不会更改的参数（即Python解释器的位置）
    • 您的观点
      它们是全局的，可以从任何地方访问，从体系结构的角度来看，这不太优雅，但限制了代码的数量
      让我想起了使用全局变量的理由；）
    我亲身体验过环境变量过度使用的恐怖后留下的疤痕

    • 我们工作时需要两个程序，由于环境冲突，它们不能在同一台计算机上同时运行
    • 多个同名但有不同bug的程序版本——由于程序的位置是从环境中提取出来的，并且（无声地、微妙地）错误了，所以整个工作坊都陷入了数小时的困境
    2） 极限

    如果我突破了命令行所能承受的极限，或者环境所能处理的极限，我会立即进行重构

    我过去在命令行应用程序中使用过JSON，它需要很多参数。能够使用字典和列表以及字符串和数字是非常方便的。应用程序只接受了几个命令行参数，其中一个是JSON文件的位置

    此方法的优点

    • 与CLI库交互不需要编写很多（痛苦的）代码——让许多公共库强制执行复杂的约束可能是一件痛苦的事情（所谓“复杂”，我的意思是比检查特定的键或alte更复杂） 
      $ command --arg=myarg

      $ ARG=myarg command

      alias cfg='git --git-dir=$HOME/.cfg/ --work-tree=$HOME'  # for dotfiles
alias grep='grep --color=auto'

      args = parser.parse_args()