我试图使用现有的代码库,但遇到了问题。简而言之,我执行一个shell脚本(让我们称之为
A
)谁的
第一幕
是调用另一个脚本(
B
). 脚本
B
位于我当前的目录中(这是我使用的程序的要求)。软件手册参考了
bash
,但是评论在
A.
表明它是在
ksh
我一直在做手术
猛击
到目前为止。
里面
A.
,要执行的行
B
简单地说:
. B
它使用“点空间”语法来调用程序。它不会做任何不寻常的事情,比如
sudo
.
当我打电话的时候
A.
没有点空间语法,即:
./A
它总是错误地说找不到文件
B
我补充道
pwd
,
ls
,
whoami
,
echo $SHELL
,以及
echo $PATH
线到
A.
调试并确认
B
事实上,就在那里,脚本正在以相同的方式运行
$SHELL
当我在命令提示符下时,该脚本与我是同一用户,并且该脚本具有相同的搜索路径
$PATH
正如我所做的那样。我还验证了我是否这样做:
B
在命令行上,它工作得很好。但是,如果我更改内部的语法
A.
致:
./B
相反,那么
A.
成功执行。
同样,如果我执行
A.
使用点空间语法,然后两者都使用
. B
和
./B
工作。
总结
:
./A
仅在以下情况下有效
A.
包含
B
语法。
. A
工作为
A.
无论是
B
或
B
语法。
我理解使用点空间(即。
A.
)语法执行时不会分叉到子shell,但考虑到文件显然就在那里,我看不出这会导致我观察到的行为。我是否缺少语法或父/子进程工作区的细微差别?魔术?
更新1
:添加的信息表明该脚本可能是在
ksh
,当我使用时
猛击
.
更新2
:添加了检查以验证
$PATH
是一样的。
更新3
:剧本说这是为
ksh
,但它正在磨合
猛击
针对Kenster的回答,我发现跑步
bash -posix
然后
B
在命令行上失败。这表明命令行和脚本之间的环境差异在于后者正在运行
猛击
在POSIX兼容模式下,而命令行则不是。再近一点看,我在
猛击
man
页面:
当作为sh调用时,bash在读取启动文件后进入posix模式。
这个
shebang
对于
A.
确实如此
#!/bin/sh
.
总之,当我跑步时
A.
如果没有点空间语法,它将分叉到自己的子shell,该子shell处于POSIX兼容模式,因为
谢邦
是
#!/bin/sh
(例如。,
#!/bin/bash
这是命令行和脚本运行时环境之间的关键区别,导致
A.
无法找到
B
.
