如今Debian和Ubuntu中，/bin/sh默认已经指向dash，
这是一个不同于bash的shell，它主要是为了执行脚本而出现，而不是交互，它速度更快，但功能相比bash要少很多，语法严格遵守POSIX标准。所以由于语法问题也许会产生在rc.local 中自定义脚本无法执行的情况
下面介绍一些语法区别
重定向：
Bash
&file 重定向标准输出和标准错误输出至file， 常见用法 >&/dev/null，其他用法 >/dev/null 2>&1
Dash
&file file不支持非数字，替代用法 >/dev/null 2>&1
写脚本的时候不是要指明解释器的吗，应该不会有这种情况吧，除非没有#!/bin/bash或你指定了#!/bin/sh:o
标题党，我还以为你要说unity的那个Dash呢，这个应该小写D，dash。。。。
:6_126:
在/etc/rc.local 中指定了 /bin/sh
所以当你在里面放一些自启动脚本时，会以dash来执行
而两者之间有语法区别，而且sh 后边指定了 -e，当脚本出现错误时，就不会继续执行了，最终所需要自启动的程序没有正常启动
其实我想明天再来回复你的来着，哈哈
dash 只是在开机时用（速度比bash快）。开机以后，一般使用者的指定shell （即 interpreter） 预设值都是 /usr/bin/bash，因此我们不必特别注意bash跟dash的差别。但我们对脚本的执行环境应该有一些基本上的了解。
即使一个脚本的shebang(#!)叙述用的是 #!/bin/sh （链接到 /bin/dash），如果我们把该执行档当成bash的执行变数，即
bash ./<脚本>
这个列在第一行的shebang叙述就会被忽略掉，而以bash执行。
反过来说，最常见的问题就是用 sh 来执行一个脚本：
sh ./<脚本>
在这种情况之下，即使这个脚本的shebang(#!)叙述用的是 #!/bin/bash，它也会被忽略掉，让这个脚本被以dash来执行。
由上面的例子来看，最安全的办法乃是，不要把脚本当作执行档来执行 （即不要用 ./<脚本>），而是养成使用 “bash ./<脚本> ”的习惯。这个建议，对新手来讲，一点问题都没有，但老手因为习惯使然，很难改过来。:lol
pyhton 的执行档里，我们常常看到这个 #!/usr/bin/env python 的shebang叙述，原因是，并不是每一个Linux distro都是把 python 放在 /usr/bin里。但跟上面所说到的bash一样，最好的办法，还是规规矩矩的把 python这6个字母拼出来： python ./<python脚本> 。如果要用python 3 执行，则用 python3 ./<python脚本> 即可 。目前（UK1310），/usr/bin/python 仍是被链接到 /usr/bin/python2.7。
楼上的建议非常好:4_87:
嗯 很好的见解
