使用定界符时，为什么关闭标准输入作为输入外壳

我有点这个使用定界符时，为什么关闭标准输入作为输入外壳

$ bash <<EOF 
    read -p 'This will not work' input 
EOF

因为

$ cat script 
read -p 'This will work fine' input 
$ bash script 
This will work fine

什么区别感到困惑？这似乎是一种标准行为，因为ash的行为方式完全相同。

根据迄今为止提供的答案，我怀疑（并确认）下列作品。我认为这实际上是我一直想做的事情，但<()语法总是我忘记的一种。

$ bash <(cat <<EOF 
    read -p 'This works' input 
EOF 
)

来源

2016-10-30 Huckle

由于read是一个bash内建函数，它继承了如上所述的bash的stdin。在第一种情况下，bash具有一个作为标准输入（或更专业的文件描述符0）的here文档，并且没有任何可用于读取的read。
read只有从标准输入（fd0）读取，而在第二种情况下，bash打开另一个文件描述，而不是标准输入从script，这确实与标准输入传递给read不冲突读剧本，让那些打算read可以工作。

你可以试试这个来测试。如果比较从样品波夫输出

$ bash << EOF 
ls -l /proc/$$/fd 
EOF

和

$ cat script.sh 
ls -l /proc/$$/fd 
$ bash script.sh

的区别是显而易见的。

来源

2016-10-30 13:38:21 iBug

你不能每个进程多个同时stdin，所以这里文档作为输入传递给bash不能包含read -p。

随着bash script，运行script是Bash shell中的一个子进程并没有并发stdin到read，从而预期它会工作。

来源

2016-10-30 08:08:50 SLePort

在这两种情况下，read命令都从执行它的bash进程继承其标准输入。

在第一个例子中，这意味着这里的文档实际上是包含的read命令。根据bash已经读取的文档的大小（通常是全部），read没有任何内容可以读取，因此它以非零退出状态退出。

在第二个示例中，bash打开不同的文件描述符上的指定文件。 read仍继承bash进程的标准输入，但此时bash根本没有读取它，因此read命令将获取下一个可用行。这里的标准输入是终端，因此read会阻塞，直到用户输入一行。

来源

2016-10-30 13:18:56 chepner

使用定界符时，为什么关闭标准输入作为输入外壳

回答

相关问题