為什么命令在運行前被Bash擴展？

Question

我正在運行命令find . -name *.bak find . -name *.bak並收到錯誤"Paths must precede expression"錯誤。 這個問題已經回答，答案是相當不錯的，但是我不明白的是為什么bash為什么在執行find命令之前會擴展通配符？ 原始的例子 。

它說find . -name *.bak find . -name *.bak展開以find . -name tim.bak example.bak find . -name tim.bak example.bak 。 有人可以解釋為什么它被擴展，但我不明白為什么為glob具有此功能是一個好主意。

Answer 1

這是在Unix歷史的早期就做出的設計決定。 文件名通配符需要在某個時候進行擴展，但是可以選擇是否由命令解釋器（也稱為shell）完成，並將結果（匹配文件列表）移交給可執行文件，還是命令解釋器僅應將其提供給可執行文件，然后進行擴展。 不同的操作系統執行此操作的方式有所不同。 unix是第一種，而VMS（我是在遷移到unix之前使用的）是第二種。 兩者都有優點和缺點。

• Unix方式的主要優點是通配符擴展代碼僅需在一個位置（在shell中）編寫和使用。 普通命令不必擔心。 其次，您可以通過在一個地方進行更改來改進/擴展匹配的語法（例如bash的extglob語法）。 第三，您在所有不同的命令之間都具有一致的擴展語法（相對於必須為不同的命令學習不同的規則，例如基本vs.擴展vs. perl兼容的regex混亂）。

• VMS方式的主要優點是可執行程序知道參數的含義，並且可以適當地更改/抑制擴展。 例如， find不會在當前目錄中擴展通配符， grep不會像文件通配符那樣嘗試擴展正則表達式模式， scp可以在遠程計算機上擴展通配符，等等。第二個優勢是因為通配符可以以unix系統根本不允許的方式使用，因為該程序可以更深入地了解如何指定參數； 例如， rename *.jpeg *.jpg （如果我沒記錯的話）是一個非常好的VMS命令，它完全按照其應有的方式工作。

  [編輯]另一個優點是，它避免了文件名被誤認為命令選項的風險。 對於unix方法，這可能是一個嚴重的安全問題，因為可以控制文件名的任何人也可以控制與這些文件一起使用的命令和腳本。 例如，創建名為“ -e somecommand”的文件將導致rsync -t * foo:src/在遠程計算機上執行somecommand 。 本文提供了更多示例。

  每個程序進行自己的通配符擴展的需求並沒有您想象的那么糟糕。 有處理擴展的標准庫函數，因此程序需要做的就是調用它，然后在生成的文件列表上工作，沒什么大不了的。 而且這些庫函數可以像shell語法一樣進行擴展，並且對其進行標准化可在程序之間提供一致性。

從上面的內容中您可以看出，我總體上認為VMS方式更好。 對於程序員來說，這還需要做更多的工作，但是在可用性和功能上具有明顯的好處。 但是我敢肯定，在UNIX人士中這是少數派觀點，無論如何，要改變UNIX的方式需要付出巨大的努力，因此只要Unix是Unix，就不會改變。

Answer 2

一個很簡短的答案：

事情是這樣的Bash工作，但它隨時擴展什么，他可以通過它們的值替代變量，使用環境變量（如$PATH例如），解釋別名和結果（相應參數）傳遞給“ 適當的 ”命令（從$PATH提取）。 論點擴展可以看作是無數責任的重擔之一。

想象一下，如果您沒有此功能，則需要為開發的每個程序實現此功能，以正確擴展參數（在工作目錄或指向的目錄中具有相應的文件）。 簡而言之，這將是一場噩夢！！！ 這就是為什么它集中在bash中。

最后但並非最不重要的一點是，對於您的find命令，請以這種方式更改它，以避免來自bash的任何干擾。 這樣， find命令將從字面上接收正則表達式作為文件名，以正確搜索和管理它

find . -name '*.bak'
             ^     ^

殼牌職責清單：

http://www.informit.com/articles/article.aspx?p=31480&seqNum=4 http://ptgmedia.pearsoncmg.com/images/chap3_0672324903/elementLinks/03fig08.jpg http://tldp.org/LDP/ abs / html / x9644.html

Answer 3

UNIX的創始者之一Dennis Ritchie給出了以下解釋：

“將這種擴展機制放到外殼中有幾個優點：代碼只出現一次，因此不會浪費空間，並且一般來說命令不需要采取特殊操作；該算法肯定會統一應用。”

DMRitchie，在Unix分時系統中：回顧性 BSTJ，1978年7月至8月