在man(1) env
中说:
env [OPTION]... [-] [NAME=VALUE]... [COMMAND [ARG]...]
请考虑print_A.sh
:
#!/usr/bin/env A=b bash
echo A is $A
当我使用./print_A.sh
运行时,它会挂起。
使用strace ./print_A.sh
运行它我得到以下日志,重复:
execve("/path/to/print_A.sh", ["/path/to/print_A.sh"...], [/* 114 vars */]) = 0
uname({sys="Linux", node="my-host", ...}) = 0
brk(0) = 0x504000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2a95556000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=171528, ...}) = 0
mmap(NULL, 171528, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2a95557000
close(3) = 0
open("/lib64/tls/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240\305\30100\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1641152, ...}) = 0
mmap(0x3030c00000, 2330696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x3030c00000
mprotect(0x3030d30000, 1085512, PROT_NONE) = 0
mmap(0x3030e2f000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12f000) = 0x3030e2f000
mmap(0x3030e35000, 16456, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x3030e35000
close(3) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2a95581000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2a95582000
mprotect(0x3030e2f000, 16384, PROT_READ) = 0
mprotect(0x3030b14000, 4096, PROT_READ) = 0
arch_prctl(ARCH_SET_FS, 0x2a95581b00) = 0
munmap(0x2a95557000, 171528) = 0
brk(0) = 0x504000
brk(0x525000) = 0x525000
open("/usr/lib/locale/locale-archive", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=48529088, ...}) = 0
mmap(NULL, 48529088, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2a95583000
close(3) = 0
如下所述,在hash-bang中运行命令并不等同于在命令行上运行它,但是,为什么它会进入无限循环?
答案 0 :(得分:3)
这个答案有两个部分。已经在duplicate question中给出了一个。然而,那里的答案解释了问题的根本原因,而不是实际发生的事情。
第1部分 - 导致这种情况的原因是什么?
Hashbang解析从未真正标准化。 Here是Sven Mascheck的一篇非常好的文章,其中还包含一个表格,其中包含不同操作系统的行为。
该表显示例如Linux在一个中执行所有args,这意味着#!/usr/bin/env A=b bash
以env
作为第一个参数执行'A=b bash'
。
第2部分 - 为什么无限循环?
执行的是env
,它设置环境变量A='b bash'
,然后重新执行原始脚本。这导致内核再次重新解释hashbang,我们得到一个无穷无尽的env
- exec循环。
第一行test.sh
的文件#!/bin/sh param
执行/bin/sh
'/bin/sh' 'param' 'test.sh'
。脚本名称作为新的命令行参数附加(即argv
)。
因此,在示例中,env
实际上是以/usr/bin/env 'A=b bash'
script_name
执行的。
env
因此会执行它所说的内容,设置变量并执行 script_name
。这又开始了hashbang解释,我们得到了循环。
答案 1 :(得分:0)
添加正在发生的情况的示例,以补充已接受的答案:
我们可以制作一个可执行文件,仅显示调用它的参数,并将其放在shebang行中:
$ cat showargs.c
#include <stdio.h>
int main(int argc, char *argv[]) {
int i;
for (i = 0; i < argc; i++)
printf("arg %d = '%s'\n", i, argv[i]);
return 0;
}
$ gcc -Wall -o /tmp/showargs showargs.c
$ cat testscript
#!/tmp/showargs A=b bash
(rest of script itself ignored here)
$ chmod +x testscript
$ ./testscript
arg 0 = '/tmp/showargs'
arg 1 = 'A=b bash'
arg 2 = './testscript'
请注意,这里的A=b bash
是单个命令行参数。
与此相反:
$ /tmp/showargs A=b bash ./testscript
arg 0 = '/tmp/showargs'
arg 1 = 'A=b'
arg 2 = 'bash'
arg 3 = './testscript'
命令行通过调用shell标记化。
因此,用env
代替showargs
,我们得到了如所接受答案中所述的无限循环(将A
设置为b bash
,并重新调用相同的脚本再次)。