./和sh的区别～～～～

[zwjiong]

写了一个最简单的shell程序～～～
#!/bin/bash

STR="Hello World"
echo $STR

但是在使用./运行的时候竟然说是 command not found
但是使用sh命令就可以～～～
然后看了下sh,其实是一个指向dash的软链接，不是指向bash的，晕掉了～～～望大侠帮我理理其中的关系

[xhy]

ubuntu中默认不再是bash了 取而代之的是dash

./执行时，shell找/bin/bash当然找不到了

sh执行时，忽略掉#开头的行，直接使用sh作为解释器

[zwjiong]

但是我在／bin 下面能够找到bash和dash阿～～

[hgshlg]

运行权限？

[princelai]

sudo chmod a+x XXX

[zwjiong]

直接使用./会提示权限不够~~~
但是如果使用sudo ./那就提示我之前所说的“command not found”

[leeyee]

脚本写完了一定要加上可执行权限才能执行的。

代码： 全选

chmod u+x xxx.sh

[xyywll]

直接使用./会提示权限不够~~~
但是如果使用sudo ./那就提示我之前所说的“command not found”

sudo 的后，你的 PATH 环境变量用的是 root 的，so。。

[zwjiong]

直接使用./会提示权限不够~~~
但是如果使用sudo ./那就提示我之前所说的“command not found”

sudo 的后，你的 PATH 环境变量用的是 root 的，so。。

能不能解释的清楚点，小弟还是不大懂~~~
这个脚本我不是用root用户建立的（忘记用ls看了），所以用sudo之后其实以root用户执行，是不是就出现问题了~~~

[leeyee]

直接使用./会提示权限不够~~~
但是如果使用sudo ./那就提示我之前所说的“command not found”

sudo 的后，你的 PATH 环境变量用的是 root 的，so。。

跟环境变量没有关系的，./就是执行当前目录下的脚本么，只要脚本有执行权限，即使是sudo也是可以执行的。
之所以你sudo ./xxx会出现command not found是因为脚本没有权限，因此shell解释器没有解释./的意义，sudo就认为你输入的命令叫./xxx，而不是xxx。
而用sh xxx.sh可以执行是因为shell解释器把xxx.sh解释为sh命令的输入，这样当然是可以的。

[zwjiong]

直接使用./会提示权限不够~~~
但是如果使用sudo ./那就提示我之前所说的“command not found”

sudo 的后，你的 PATH 环境变量用的是 root 的，so。。

跟环境变量没有关系的，./就是执行当前目录下的脚本么，只要脚本有执行权限，即使是sudo也是可以执行的。
之所以你sudo ./xxx会出现command not found是因为脚本没有权限，因此shell解释器没有解释./的意义，sudo就认为你输入的命令叫./xxx，而不是xxx。
而用sh xxx.sh可以执行是因为shell解释器把xxx.sh解释为sh命令的输入，这样当然是可以的。

3Q~~解释的很明白，我刚刚也用chmod改了执行权限现在可以了~~~非常感谢啊~~

[Dic4000]

直接使用./会提示权限不够~~~
但是如果使用sudo ./那就提示我之前所说的“command not found”

sudo 的后，你的 PATH 环境变量用的是 root 的，so。。

跟环境变量没有关系的，./就是执行当前目录下的脚本么，只要脚本有执行权限，即使是sudo也是可以执行的。
之所以你sudo ./xxx会出现command not found是因为脚本没有权限，因此shell解释器没有解释./的意义，sudo就认为你输入的命令叫./xxx，而不是xxx。
而用sh xxx.sh可以执行是因为shell解释器把xxx.sh解释为sh命令的输入，这样当然是可以的。

不错，学习了

[xyywll]

ls 三位朋友，我的感觉不是如此

你输入的任何命令都会被 shell 解析，除非用 quoting，不然 ./ 应该是被 shell 解析的，命令自然只是 ./ 后面的命令
比如脚本 haha.sh 用 strace 跟踪 sudo ./haha.sh 得到：
execve("/usr/bin/sudo", ["sudo", "haha.sh"], [/* 41 vars */]) = 0
显然，sudo 的参数是 haha.sh 而不是 ./haha.sh ， ./ 被 shell 解析了
原因是什么，我还不知道，我弄完手头的事情，准备跟踪下执行过程

大家可以做做实验：
在 /bin 下面自己建立一个脚本，比如 haha.sh ， 但不给 +x 权限，这样 sudo 的时候，一定会搜索到 /bin 目录，输入
sudo haha.sh
一样提示： sudo: haha.sh: command not found
所以我觉得是别的问题

我觉得真实的原因是：
1. 你给 shell 一个文本文件（类型是使用 文件头 探测到的），实际上就是给 shell 的一系列指令的集合，此时 haha.sh 不是一个可执行文件，而是一个文本文件，执行的实际是 当前shell名 haha.sh ，lz 的例子就是 bash haha.sh
但在执行前，先要检测有没有 +x ，因为没有，所以提示 Permission denied
如果 +x 了，执行的就是
bash haha.sh
2. sudo 的时候， sudo 后面的东西是被 shell 解析后作为 sudo 的参数，实际上是作为 execve 系统调用的实参来执行的，而 execve 能够启动的只能是一个 ELF a.out 等格式的可执行文件，所以用 sudo ./haha.sh ， haha.sh 被作为一个可执行文件来传递给 execve ，显然它不是ELF a.tou （同样用文件头探测），execve 不了，所以说 command not found

一些想法，没验证，大家可以自己先调试下

[leeyee]

ls 三位朋友，我的感觉不是如此

你输入的任何命令都会被 shell 解析，除非用 quoting，不然 ./ 应该是被 shell 解析的，命令自然只是 ./ 后面的命令
比如脚本 haha.sh 用 strace 跟踪 sudo ./haha.sh 得到：
execve("/usr/bin/sudo", ["sudo", "haha.sh"], [/* 41 vars */]) = 0
显然，sudo 的参数是 haha.sh 而不是 ./haha.sh ， ./ 被 shell 解析了
原因是什么，我还不知道，我弄完手头的事情，准备跟踪下执行过程

大家可以做做实验：
在 /bin 下面自己建立一个脚本，比如 haha.sh ， 但不给 +x 权限，这样 sudo 的时候，一定会搜索到 /bin 目录，输入
sudo haha.sh
一样提示： sudo: haha.sh: command not found
所以我觉得是别的问题

我觉得真实的原因是：
1. 你给 shell 一个文本文件（类型是使用 文件头 探测到的），实际上就是给 shell 的一系列指令的集合，此时 haha.sh 不是一个可执行文件，而是一个文本文件，执行的实际是 当前shell名 haha.sh ，lz 的例子就是 bash haha.sh
但在执行前，先要检测有没有 +x ，因为没有，所以提示 Permission denied
如果 +x 了，执行的就是
bash haha.sh
2. sudo 的时候， sudo 后面的东西是被 shell 解析后作为 sudo 的参数，实际上是作为 execve 系统调用的实参来执行的，而 execve 能够启动的只能是一个 ELF a.out 等格式的可执行文件，所以用 sudo ./haha.sh ， haha.sh 被作为一个可执行文件来传递给 execve ，显然它不是ELF a.tou （同样用文件头探测），execve 不了，所以说 command not found

一些想法，没验证，大家可以自己先调试下

其实你误会我的意思了。就拿你的例子来说吧，我已经说了sudo检查了haha.sh，但是发现它没有执行权限(也就是说不是可执行文件)，所以它就不再进一步向下走了。“./”自然是已经被shell认出来了，否则它也不会去检查haha.sh是否可执行呀！ 只是它不再做进一步动作罢了。我说它没有被解释只是为了方便楼主理解。

你已经看到系统调用这一层，很赞！

[lujinke]

你用的什么版本的Ubuntu啊，我用7。10可以很好的运行没有你说的问题。
而且也不是想上面的人说的没有/bin/bash,而是/bin/bash ,/bin/dash

写了一个最简单的shell程序～～～
#!/bin/bash

STR="Hello World"
echo $STR

但是在使用./运行的时候竟然说是 command not found
但是使用sh命令就可以～～～
然后看了下sh,其实是一个指向dash的软链接，不是指向bash的，晕掉了～～～望大侠帮我理理其中的关系