我以前做过Bash脚本，在开始时没有#!/bin/bash它们都运行得很好。
#!/bin/bash
放进去有什么意义?事情会有什么不同吗?
还有，#怎么发音?我知道!的发音是“bang”。
#
!
#!怎么发音?
#!
这是一个约定，因此*nix shell知道要运行哪种解释器。
例如，旧版本的ATT默认为上海 (Bourne shell)，而旧版本的BSD默认为csh (C shell)。
即使在今天(大多数系统运行bash， 《谍影重重，炮弹》)，脚本也可以是bash、python、perl、ruby、PHP等等。例如，您可能会看到#!/bin/perl或#!/bin/perl5。
#!/bin/perl
#!/bin/perl5
操作系统采用默认shell来运行shell脚本。所以在脚本的开头提到shell path，你是在要求操作系统使用那个特定的shell。它对可移植性也很有用。
每个发行版都有一个默认shell。Bash是大多数系统的默认设置。如果您恰巧在一个具有不同默认shell的系统上工作，那么如果脚本是专门为Bash编写的，那么它们可能无法正常工作。
Bash多年来一直在从ksh和sh中获取代码。
ksh
sh
添加#!/bin/bash作为脚本的第一行，告诉操作系统调用指定的shell来执行脚本中接下来的命令。
shell
#!通常被称为“hash-bang”，“she-bang”或“sha-bang”。
它被称为工作。在unix语言中，#被称为sharp(就像在音乐中)或hash(就像twitter上的标签)，而!叫做bang。(实际上，您可以使用!!，叫bang-bang)。所以当组合在一起时，你会得到haSH-BANG，或shebang。
#!告诉Unix使用什么程序来运行它。如果它没有指定，它将尝试使用bash(或sh，或zsh，或任何你的$SHELL变量)，但如果它在那里，它将使用该程序。另外，#在大多数语言中是注释，因此在后续执行中会忽略该行。
它被称为工作。它由一个数字符号和一个感叹号字符(#!)组成，后面跟着到解释器的完整路径，例如/bin/bash.UNIX和Linux下的所有脚本都使用第一行中指定的解释器执行。
工作是一个指令，指示加载器在尝试执行文件时使用#!后面指定的程序作为解释器。因此，如果您试图运行一个名为foo.sh的文件，其中顶部有#!/bin/bash，实际运行的命令是/bin/bash foo.sh。这是一种为不同程序使用不同解释器的灵活方式。这是在系统级实现的，用户级API是shebang约定。
foo.sh
/bin/bash foo.sh
还有一点值得注意的是，shebang是神奇的数字——一个人类可读的文件，它将文件标识为给定解释器的脚本。
您所说的即使没有shebang它也能“工作”的观点只是因为所讨论的程序是为与您正在使用的shell相同的shell编写的shell脚本。例如，你可以很好地编写一个javascript文件，然后放入#! /usr/bin/js(或类似的东西)来拥有一个javascript“Shell脚本”。
#! /usr/bin/js
更准确地说，工作 #!，当它是可执行的 (x 模式)文件的前两个字节时，由execve (2)系统调用解释(执行程序)。但是execve的POSIX规范不要提shebang。
x
execve
它必须跟在解释器可执行文件的文件路径后面(BTW甚至可以是相对的，但大多数情况下是绝对的)。
在用户的$PATH中找到一个解释器(例如python)的一个不错的技巧(或者可能是不太好之一)是使用env程序(在所有Linux上总是在/usr/bin/env)，例如:
$PATH
python
env
/usr/bin/env
#!/usr/bin/env python
任何ELF可执行文件都可以是解释器。你甚至可以使用#!/bin/cat或#!/bin/true，如果你想!(但这通常是没有用的)
#!/bin/cat
#!/bin/true
对于使用不同系统而没有现成库的人来说，它可能很有用。如果没有声明，并且脚本中有一些系统不支持的函数，则应该声明#/bin/bash。我以前在工作中遇到过这个问题，现在我只是把它作为一种实践。
shell是一个接受并运行命令的命令行解释器。
简单地开始您的bash脚本到#!/bin/bash
