2014-03-02 25 views
0

我有一个脚本改变了另一个程序的一些东西,其中一个是用一组不同的标志调用所述程序。

标志很长,容易出错并且难以记住,所以我写的这个脚本想要覆盖该可执行文件,这样当用户调用脚本时,它实际上会调用脚本以及额外的复杂参数。

我知道的至少3种方式来实现上述:

  • 创建一个别名:alias foo=/usr/bin/foo --compicated-flag ComplexArgument
  • 创建一个函数:

    function foo { 
        /usr/bin/foo --compicated-flag ComplexArgument 
    } 
    
  • 改变$PATH使非-文件的标准位置在用户实际使用foo之前被调用,其中包含以下内容:

    /usr/bin/foo --compicated-flag ComplexArgument 
    

我的问题是,我希望用户能够运行一个脚本,将这些设置与只是一个命令。我不想通过第二个动作提示用户,例如“现在您需要输入此文件或每次输出$PATH”。

由于ComplexArgument被编程来计算,并将其变化很大,无论是alias也不function方法将工作(例如,宣布那些在bashrczshrc)。同样重要的是要注意,这些更改应该只是临时的,并且用户可能会或可能不想要设置它。更多理由不应将这些更改添加到RC shell文件中。

所以我唯一回避的事情就是改变$PATH

我知道要更改环境变量并影响子外壳,我需要拨打exec。例如:

export PATH=/path/to/other/foo:$PATH 
    exec $SHELL 

这样$PATH会“粘”到子shell。

除此之外,在某些环境下,它肯定不会。

例如在OSX中,如果您安装了HomeBrew,建议您更改$PATH,以使/usr/local/bin位于第一位,以便HomeBrew安装的库首先出现。

如果用户在他的.zshrc喜欢定义它:

PATH=/usr/local/bin:$PATH 

这意味着,不管是什么我的脚本设置,ZSH将读取.zshrc文件,并得到/usr/local/bin第一。

如果我使用ZSH的标志之一,以避免读取用户的RC文件,然后其他的事情将停止工作,因为$PATH将不再正确设置和ZSH将总是呼叫/etc/zshenv这在一些系统中有这样的:

# system-wide environment settings for zsh(1) 
if [ -x /usr/libexec/path_helper ]; then 
    eval `/usr/libexec/path_helper -s` 
fi 

这使事情变得更糟,因为这改变$PATH,以确保一些路径来之前不管是什么$PATH以前。

因此,我发现两个第一项(aliasfunction)不够充分,第三个(更改$PATH)是不可靠的。

我知道必须有一个正确的方法来做到这一点,我理解子shell的局限性,并改变一个脚本中的内容并使它们保持不变,但会提示用户“源文件修改为$PATHexport PATH=/path/to/foo:$PATH“使这个可靠的唯一方法?

+0

经常变化的冗长复杂的论点?听起来像'ghostscript'。无论如何,我会将'/ usr/local/bin/whatever'移动到'/ usr/local/bin/whatever.installed'上,然后在''/ usr/local/bin/exec'安装的版本。 – bishop

回答

0

第四个选项将是复杂函数的一个包装。因此,您可以将复杂的脚本从complicated重命名为complicated.orig,然后编写一个新的complicated计算参数,然后使用新计算的参数计算exec的complicated.orig。这样您就不会依赖于所有更新其登录配置文件以使用您的别名或功能的用户,并且脚本的路径将与用户的历史一样。

0

在部署软件包中提供助手脚本是一种非常常见的技术。认为service apache2 restart完全符合你的描述。