sh当以交互方式使用以及在 Bash 脚本内部使用时， 该命令的用途是什么？
除了哈希标记行（第一行）之外，是否应该在 bash 系统上sh进行替换？bash
例子：
#!/bin/bash
sh -c "command"
答案1
问题太多了...我将一一解答。
1) sh 命令在交互使用时的目的是什么？提供新的环境上下文，因此如果您想尝试某些环境变量设置，您可以这样做。完成后，exit退出，不会造成任何损害。
另外，如果您处于不同的 shell 中（例如 zsh 或 csh），并且想要在shshell 中执行，这将切换您。
2）当像上面一样在 bash 脚本中使用时，它将再次为“命令”提供包含的环境上下文来运行。您还可以将它与
#!/bin/bash
sh -c "command" &
3) 我想说，如果它是特定需要的东西bash，那么请明确将其放入哈希爆炸行中。但由于在大多数较新的 *nix 系统上，它sh相当于bash，所以可能没有必要。
答案2
当我执行时会发生什么sh？
如果你只是sh在 shell 上启动，你就会启动当前 shell 中的另一个 shell。
当我sh在脚本中使用时会发生什么？
同样的事情，你在处理脚本的shell里面启动另一个shell。
我应该简单地使用/bin/bashif 这就是所/bin/sh指向的吗？
不. 如果脚本设计用于任何shell，那么它的设计就是为了满足所有 shell 之间的最低公分母（据我理解，这是POSIX 标准）。
更改为具体的解释器不应该是有害的（因为它们都遵循相同的标准）但它降低了兼容性而没有任何好处。
那么，我应该一直使用/bin/sh吗？
作为翻译
不。如果你在写剧本你自己，那么您也可以使用更具体的解释器（如 bash），如果该解释器提供了您想要使用的附加功能。但请记住，每个使用您的脚本的人都需要有您选择的解释器。
启动另一个进程
如果您只是想在其自身上下文中启动一个新进程，那么，请务必使用/bin/sh。
那么这一切的意义是什么？
如果你想执行某件事在其自身背景下，则应在新 shell 中执行该命令。
最简单的方法是启动新 shell（使用sh）并将命令传递给它。
只要你的某物不是专门为特定 shell 编写的脚本，因此没有必要调用特定 shell。只需调用任何shell，通过使用sh。
如果您有一个脚本，使用仅在中可用的特殊语法bash，那么您应该设置舍邦因此。
答案3
为什么是/bin/sh??
正如其他人指出的那样，您可以决定这实际上意味着什么:)（或者您的发行版为您决定。）
对于 bash 来说至少它具有特殊的含义...
来自 bash 手册页：
“如果使用名称 sh 调用 bash，它会尝试尽可能地模仿 sh 历史版本的启动行为，同时也符合 POSIX 标准。”
因此，如果您的 /bin/sh 指向 /bin/bash，那么您就会得到该行为。
/bin/bash #!/bin/bash
给你“标准”的bash（及其“批判”）
当然，/bin/sh 实际上可能是指向 /bin/dash 或 ksh 或其他“shell”的链接。
bash 手册页很长，但这个特定信息只有……145 行:)
有几个很好的介绍：高级 Bash 脚本指南非常棒。
如果你使用的是 Debian / Ubuntu (或其他衍生版本)：
abs-guide - 高级 Bash 脚本指南
debian-reference-en -> Debian 系统管理指南，英文原版
例如
apt-get install abs-guide
仅供参考：（编辑至描述）
$ apt-cache 显示破折号
说：
描述：符合 POSIX 标准的 shell Debian Almquist Shell
(dash) 是从 ash 派生出来的符合 POSIX 标准的 shell。
由于它执行脚本的速度比 bash 快，
并且库依赖性更少
（使其更能抵御软件或硬件故障），
它在 Debian 系统上用作默认系统 shell。
主页：
答案4
1) 它是一个 shell。它在交互模式下的目的是读取用户的输入并执行指定的命令。在非交互模式下，它从脚本文件中读取所有命令，因此它无需用户触摸键盘即可工作。
2) “sh -c 命令”与脚本文件中的“命令”之间的区别在于，前者命令是从单独的 shell 进程派生的，而后者是从运行主 shell 脚本的进程派生的（即可以访问其文件描述符、环境等）。因此，前者在进程树中拥有额外的进程，并且具有一定程度的隔离性。
3) /bin/sh 可能是 /bin/zsh 的符号链接（例如），所以，是的，如果您想要从 bash 主脚本运行 bash 子脚本，则应明确地说“bash -c”。如果子脚本独立于 shell，则“sh -c”也可以。