在 Linux 中像 MSYS2 一樣處理帶有 CRLF（回車符）的 Bash 腳本？

Question 1

據我所知，沒有辦法告訴 Bash 接受 Windows 風格的行結尾。

在涉及 Windows 的情況下，常見的做法是依靠 Git 在提交時使用autocrlf配置標誌自動轉換行結尾的功能。請參閱範例GitHub 有關行結尾的文檔，這不是 GitHub 特有的。這樣，文件就會在儲存庫中以 Unix 風格的行結尾提交，並根據每個客戶端平台進行適當的轉換。

（相反的問題不是問題：MSYS2 在 Windows 上可以很好地處理 Unix 風格的行結尾。）

Answer

據我所知，沒有辦法告訴 Bash 接受 Windows 風格的行結尾。

在涉及 Windows 的情況下，常見的做法是依靠 Git 在提交時使用autocrlf配置標誌自動轉換行結尾的功能。請參閱範例GitHub 有關行結尾的文檔，這不是 GitHub 特有的。這樣，文件就會在儲存庫中以 Unix 風格的行結尾提交，並根據每個客戶端平台進行適當的轉換。

（相反的問題不是問題：MSYS2 在 Windows 上可以很好地處理 Unix 風格的行結尾。）

Question 2

你應該使用binfmt_misc為此[1]。

首先，定義一個處理以開頭的檔案的 magic #! /bin/bash<CR><LF>，然後為其建立一個可執行解釋器。解釋器可以是另一個腳本：

INTERP=/path/to/bash-crlf

echo ",bash-crlf,M,,#! /bin/bash\x0d\x0a,,$INTERP," > /proc/sys/fs/binfmt_misc/register
cat > "$INTERP" <<'EOT'; chmod 755 "$INTERP"
#! /bin/bash
script=$1; shift; exec bash <(sed 's/\r$//' "$script") "$@"
EOT

測試一下：

$ printf '%s\r\n' '#! /bin/bash' pwd >/tmp/foo; chmod 755 /tmp/foo
$ cat -v /tmp/foo
#! /bin/bash^M
pwd^M
$ /tmp/foo
/tmp

範例解釋器有兩個問題：1.由於它通過不可查找的文件（管道）傳遞腳本，bash 將逐字節讀取它，效率非常低，並且2.任何錯誤訊息都將引用/dev/fd/63或類似的名稱而不是原始腳本的名稱。

[1] 當然，您可以建立一個/bin/bash^M指向解釋器的符號鏈接，而不是使用 binfmt_misc，這也適用於 OpenBSD 等其他系統：

ln -s /path/to/bash-crlf $'/bin/bash\r'

但在 Linux 上，shebanged 執行檔比 binfmt_misc 沒有任何優勢，並且將垃圾放入系統目錄中並不是正確的策略，並且會讓任何系統管理員搖頭;-)

Answer

你應該使用binfmt_misc為此[1]。

首先，定義一個處理以開頭的檔案的 magic #! /bin/bash<CR><LF>，然後為其建立一個可執行解釋器。解釋器可以是另一個腳本：

INTERP=/path/to/bash-crlf

echo ",bash-crlf,M,,#! /bin/bash\x0d\x0a,,$INTERP," > /proc/sys/fs/binfmt_misc/register
cat > "$INTERP" <<'EOT'; chmod 755 "$INTERP"
#! /bin/bash
script=$1; shift; exec bash <(sed 's/\r$//' "$script") "$@"
EOT

測試一下：

$ printf '%s\r\n' '#! /bin/bash' pwd >/tmp/foo; chmod 755 /tmp/foo
$ cat -v /tmp/foo
#! /bin/bash^M
pwd^M
$ /tmp/foo
/tmp

範例解釋器有兩個問題：1.由於它通過不可查找的文件（管道）傳遞腳本，bash 將逐字節讀取它，效率非常低，並且2.任何錯誤訊息都將引用/dev/fd/63或類似的名稱而不是原始腳本的名稱。

[1] 當然，您可以建立一個/bin/bash^M指向解釋器的符號鏈接，而不是使用 binfmt_misc，這也適用於 OpenBSD 等其他系統：

ln -s /path/to/bash-crlf $'/bin/bash\r'

但在 Linux 上，shebanged 執行檔比 binfmt_misc 沒有任何優勢，並且將垃圾放入系統目錄中並不是正確的策略，並且會讓任何系統管理員搖頭;-)

Question 3

好的，我找到了一些解決方法，透過：

“聯結”符號鏈接

現代 UNIX 系統有一種方法可以使任意資料顯示為文件，而與儲存方式無關：保險絲。使用 FUSE，對檔案的每個操作（建立、開啟、讀取、寫入、列出目錄等）都會呼叫程式中的某些程式碼，並且程式碼可以執行您想要的任何操作。看創建一個實際上是命令的虛擬文件。你可以嘗試一下腳本檔案系統或者熔絲，或者如果您雄心勃勃，也可以自己動手。

... 和創建一個實際上是命令的虛擬文件

您可能正在尋找命名管道。

因此，方法是：建立一個命名管道，向其dos2unix輸出，然後呼叫bash該命名管道。

這裡我有原始的tmp.shCRLF 行結尾為/tmp;首先，讓我們建立命名管道：

tmp$ mkfifo ftmp.sh

現在，如果您執行以下命令：

tmp$ dos2unix <tmp.sh >ftmp.sh

……你會注意到它會阻塞；如果你這樣做了，請說：

~$ cat /tmp/ftmp.sh | hexdump -C
00000000  65 63 68 6f 20 22 74 65  73 74 69 6e 67 22 0a 73  |echo "testing".s|
00000010  74 61 74 20 2e 0a 65 63  68 6f 20 22 74 65 73 74  |tat ..echo "test|
00000020  69 6e 67 20 61 67 61 69  6e 22 0a                 |ing again".|
0000002b

....您會注意到轉換已完成 - 並且在命令cat運行完畢後，dos2unix <tmp.sh >ftmp.sh先前阻止的命令已退出。

dos2unix因此，我們可以在「無限」while 循環中設定對命名管道的寫入：

tmp$ while [ 1 ] ; do dos2unix <tmp.sh >ftmp.sh ; done

……即使它是一個「緊密」循環，也不應該成為問題，因為大多數時候在 while 循環內的指令是阻塞的。

然後我可以這樣做：

~$ bash /tmp/ftmp.sh
testing
  File: .
  Size: 4096        Blocks: 8          IO Block: 4096   directory
Device: 801h/2049d  Inode: 5276132     Links: 7
...
testing again
$

...顯然，腳本運作良好。

這種方法的好處是我可以tmp.sh在文字編輯器中開啟原始文件；並編寫新程式碼 - 以 CRLF 結尾 - 然後儲存tmp.sh；在Linux下運行bash /tmp/ftmp.sh將運行最新保存的版本。

這樣做的問題是，像read -p "Enter user: " user這樣依賴實際終端機 stdin 的命令將會失敗；或者更確切地說，不要失敗，但如果你嘗試，請說成/tmp/tmp.sh

echo "testing"
stat .
echo "testing again"
read -p "Enter user: " user
echo "user is: $user"

……然後將輸出：

$ bash /tmp/ftmp.sh
testing
  File: .
  Size: 4096        Blocks: 8          IO Block: 4096   directory
...
 Birth: -
testing again
Enter user: tyutyu
user is: tyutyu
testing
  File: .
  Size: 4096        Blocks: 8          IO Block: 4096   directory
...
 Birth: -
testing again
Enter user: asd
user is: asd
testing
...

....等等 - 也就是說，終端機中鍵盤的 stdin 被正確解釋，但由於某種原因，腳本開始循環，並從頭開始一遍又一遍地執行（如果我們沒有命令，則不會發生這種情況read -p ...）原本的tmp.sh）。也許有一些重定向的東西（例如，在~~循環命令中添加一些0>1&或其他內容while~~；實際上，我有一個.sh腳本也開始像這樣循環，並且簡單地在腳本末尾wget添加顯式似乎可以停止腳本循環）這也可以處理這個問題，-但到目前為止，我需要使用的腳本沒有類似的命令，所以這種方法可能對我有用。exit.shread -p

Answer