使用定界符時，爲什麼關閉標準輸入作爲輸入外殼

Question

我有點這個

$ 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 
) 

Answer 1

由於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 

的區別是顯而易見的。

Answer 2

你不能每個進程多個同時stdin，所以這裏文檔作爲輸入傳遞給bash不能包含read -p。

隨着bash script，運行script是Bash shell中的一個子進程並沒有併發stdin到read，從而預期它會工作。

Answer 3

在這兩種情況下，read命令都從執行它的bash進程繼承其標準輸入。

在第一個例子中，這意味着這裏的文檔實際上是包含的read命令。根據bash已經讀取的文檔的大小（通常是全部），read沒有任何內容可以讀取，因此它以非零退出狀態退出。

在第二個示例中，bash打開不同的文件描述符上的指定文件。 read仍繼承bash進程的標準輸入，但此時bash根本沒有讀取它，因此read命令將獲取下一個可用行。這裏的標準輸入是終端，因此read會阻塞，直到用戶輸入一行。