在Deb软件包维护者脚本中，例如postinstall，prerm等我认为我们经常使用/ bin / sh作为shell脚本解释器。但是，/ bin / sh可能在不同的分发或用户首选项上有所不同。例如，Ubuntu link / bin / sh to / bin / dash，或者某些用途可能链接到/ bin / tcsh。
如果用户将shell更改为tcsh，我遇到两种类型的语法可能会失败。
1）设置-e #tcsh无法理解这一点。
2）＆gt; / dev / null 2＆gt;＆amp; 1＃ambiguous redirection。
第一个想法是删除（1），并将（2）更改为＆gt;＆amp;的/ dev / null的。但是，我在大多数维护者脚本中找到了＆＃39; set -e＆＃39;提出了一行。
现在，我不确定
a）我只是解决了所有问题并使用/ bin / sh b）更改为使用/ bin / bash c）忽略tcsh案例
任何人都可以提供一些建议吗？
谢谢。 千斤顶
答案 0 :(得分：5)
Debian policy并没有强制您使用/bin/sh作为shell，只要您正确命名（Shebang），就可以使用任何其他的一个，并且它可用在您尝试安装到的系统上（如果您在preinst脚本中使用它，则会将您限制为默认提供的shell）。
但是Debian策略告诉你/bin/sh，无论实际是什么，都将始终实现SUSv3 Shell命令语言（即：符合POSIX的shell）和一些附加功能。这就是维护者脚本所依赖的。
在Debian上，/bin/sh是/bin/bash直到Lenny。从Squeeze开始，它现在是/bin/dash。请参阅Debian wiki for more information。
在Debian或任何衍生品上，如果/bin/sh实际上与/bin/tcsh相关联，则它将是本地管理员更改的本地设置。这可能不仅会破坏你的脚本，还会破坏许多其他脚本。 Debian政策文件实际上告诉维护者避免使用csh和tcsh作为脚本语言。
总之，我认为您不应该为自己的脚本与tcsh兼容而烦恼，最佳做法是仅使用/bin/sh来满足您的所有包装需求。
如有疑问，请务必参阅完整的Debian policy document。