我有一个包含约20个小.sh文件的项目。我将这些名称命名为“小”，因为通常没有文件包含超过20行的代码。我之所以采用模块化方法，是因为我忠于Unix理念，并且对我来说维护项目更容易。

在每个.sh文件的开头，我放置了#!/bin/bash。

简而言之，我了解脚本声明有两个目的：

1. 它们帮助用户回忆起执行该文件所需的外壳程序（例如，几年后不使用该文件）。
2. 他们确保脚本仅在特定外壳程序（在这种情况下为Bash）下运行，以防止在使用其他外壳程序的情况下出现意外行为。

当一个项目开始从5个文件增长到20个文件或从20个文件增长到50个文件时（不是这种情况，只是为了演示），我们有20行或50 行的脚本声明。我承认，即使对某些人来说可能很有趣，但我对使用20或50而不是每个项目只说1个（也许在项目的主文件中）感到有点多余。

有没有一种方法可以通过在某些主文件中使用一些“全局”脚本声明来避免所谓的20或50或更多行的脚本声明冗余？

即使您的项目现在可能仅由50个Bash脚本组成，但它迟早会开始累积用其他语言（如Perl或Python）编写的脚本（这是这些脚本语言所具有的好处，而Bash没有）。

如果#!每个脚本中没有合适的-line，那么在不知道要使用哪种解释器的情况下使用各种脚本将非常困难。是否从其他脚本执行每个脚本都没有关系，这只会将困难从最终用户转移到开发人员。这两类人都不需要知道脚本使用的语言才能使用。

在没有#!-line且没有显式解释器的情况下执行的shell脚本会根据不同的shell调用方式以不同的方式执行（请参见例如哪个shell解释器运行没有shebang的脚本，尤其是Stéphane的答案），这不是您想要的在生产环境中（您想要一致的行为，甚至可能希望具有可移植性）。

无论#!-line 怎么说，使用显式解释器执行的脚本都将由该解释器运行。如果您决定重新实现，例如使用Python或任何其他语言的Bash脚本，这将导致进一步的问题。

您应该花费这些额外的击键，并始终在#!每个脚本中添加一个-line。

在某些环境中，每个项目中的每个脚本中都有多段式样的法律文本。感到非常高兴的是，这只是一条#!在您的项目中感觉“多余”的线。

您误解了#!。实际上，这是操作系统的指令，可以在定义的解释器下运行该程序。

这样就可以编写脚本，#!/usr/bin/perl并且可以按原样运行结果程序，./myprogram并可以使用perl解释器。类似的#!/usr/bin/python将导致程序在python下运行。

因此，该行#!/bin/bash告诉OS在bash下运行该程序。

这是一个例子：

$ echo $0
/bin/ksh

$ cat x
#!/bin/bash

ps -aux | grep $$

$ ./x
sweh      2148  0.0  0.0   9516  1112 pts/5    S+   07:58   0:00 /bin/bash ./x
sweh      2150  0.0  0.0   9048   668 pts/5    S+   07:58   0:00 grep 2148

因此，尽管我的外壳是ksh，程序“ x”由于该#!行而在bash下运行，我们可以在进程列表中明确看到它。

上 .sh

不好的是.sh文件名的末尾。

想象一下，您重写了python中的脚本之一。

好了，现在您必须将第一行更改#!/usr/bin/python3为还不错，因为您还必须更改文件中的所有其他代码行。但是，您还必须将文件名从更改prog.sh为prog.py。然后，您必须在其他脚本中找到所有地方，以及所有用户脚本（您甚至不知道的用户脚本都存在），然后将其更改为使用新脚本。sed -e 's/.sh/.py/g'可能会对您认识的人有所帮助。但是现在您的修订控制工具正在显示许多无关文件的更改。

或者，以Unix方式执行此操作，prog而不给程序命名prog.sh。

上 #!

如果您使用的是正确的#!，并将权限/模式设置为包括执行。然后，您无需了解口译员。计算机将为您完成此任务。

chmod +x prog #on gnu adds execute permission to prog.
./prog #runs the program.

对于非gnu系统，请阅读手册chmod（并学习八进制），也许仍然可以阅读。

[hashbang行]确保脚本仅在特定外壳程序（在这种情况下为Bash）下运行，以防止在使用其他外壳程序的情况下出现意外行为。

可能值得指出，这是完全错误的。hashbang行绝不会阻止您尝试将文件提供给错误的shell /解释器：

$ cat array.sh
#!/bin/bash
a=(a b c)
echo ${a[1]} $BASH_VERSION
$ dash array.sh
array.sh: 2: array.sh: Syntax error: "(" unexpected

（或类似地awk -f array.sh等）

但是无论如何，模块化的另一种方法是在文件中定义外壳函数，如果需要，每个文件定义一个函数，然后source在主程序中定义文件。这样，您就不需要hashbang：它们将被视为其他任何注释，并且所有内容都将使用相同的shell运行。缺点是您需要source带有功能的文件（例如for x in functions/*.src ; do source "$x" ; done），并且它们都使用相同的shell运行，因此您无法用Perl实现直接替换其中的一个。

有没有一种方法可以通过在某些主文件中使用一些“全局”脚本声明来避免所谓的20或50或更多行的脚本声明冗余？

有-这被称为可移植性或POSIX合规性。力争始终以可移植的，不依赖外壳的方式编写脚本，仅从使用#!/bin/sh或当您/bin/sh进行交互使用的脚本（或至少是POSIX兼容的外壳，如ksh）中获取脚本。

但是，可移植脚本不能使您摆脱以下困扰：

• 需要使用其中一个外壳的功能（ilkkachu的答案是一个示例）
• 需要使用比Shell更高级的脚本语言（Python和Perl）
• PEBKAC错误：你的脚本落入谁运行脚本不是用户J.Doe的手你预期它，例如它们运行/bin/sh与脚本csh。

如果我表达我的观点，那么通过消除“避免冗余” #!是错误的目标。目标应该是一致的性能，并且实际上应该是一个工作脚本，该脚本可以工作并考虑极端情况，并遵循某些一般规则，例如not-parsing-ls或always-quoting-variables-unless-word-splitting。

它们帮助用户回忆起执行该文件所需的外壳程序（例如，几年后不使用该文件）。

它们实际上不是给用户的-它们是给操作系统运行适当的解释器的。在这种情况下，“正确”表示OS找到了shebang中的内容；如果下面的代码是错误的shell，那是作者的错。至于用户内存，我认为不需要Microsoft Word或Google Chrome之类的程序的“用户”就知道要编写哪种语言程序。作者可能需要。

再说一次，可移植的脚本可能甚至不需要记住您最初使用的shell，因为可移植脚本应该可以在任何POSIX兼容的shell中使用。

他们确保脚本仅在特定外壳程序（在这种情况下为Bash）下运行，以防止在使用其他外壳程序的情况下出现意外行为。

他们没有。实际上防止意外行为的是编写可移植脚本。

之所以需要将其放在#!/bin/bash每个脚本的顶部，是因为您将其作为一个单独的进程运行。

当您将脚本作为新进程运行时，操作系统会看到它是一个文本文件（与二进制可执行文件相对），并且需要知道要执行哪个解释器。如果您不告知，则操作系统只能使用其默认设置（管理员可以更改）进行猜测。因此，该#!行（当然还要加上可执行文件的权限）将一个简单的文本文件转换为可以直接运行的可执行文件，并确信操作系统知道如何处理该文件。

如果要删除该#!行，则选项为：

1. 直接执行脚本（如您现在所做的那样），并 希望默认解释器与脚本匹配-您可能在大多数Linux系统上都是安全的，但不能移植到其他系统（例如Solaris）上，可以将其更改为任何东西（我什至可以将其设置为vim在文件上运行！）。

2. 使用执行脚本bash myscript.sh。这可以正常工作，但是您必须指定脚本的路径，而且很乱。

3. 使用提供源脚本. myscript.sh，该脚本在当前解释器进程（即，不是子进程）中运行脚本。但这几乎可以肯定需要修改您的脚本，并使它们的模块化/重用性降低。

在情况2和3中，文件不需要（也不应该具有）执行权限，并且给它一个.sh（或.bash）后缀是一个好主意。

但是这些选项都不适合您的项目，因为您说过要保持脚本模块化（=>独立且自包含），因此应将#!/bin/bash行放在脚本的顶部。

在您的问题中，您还说过您正在遵循Unix哲学。如果是这样，那么您应该了解该#!行的真正用途，并在每个可执行脚本中继续使用它！