UNIX 的歷史不包括 $PATH 中的目前目錄
在 UNIX 世界中，眾所周知，您需要在目前目錄
./中為二進製文件添加前綴才能執行它們：預設情況下.不在$PATH。這是為了避免邪惡的二進製文件覆蓋系統實用程序，例如ls並獲取程式碼執行。我想知道這個決定的歷史。從一開始就在 UNIX 中嗎？某些貝殼？
我想明確一點：我不是在尋找實施它的一般原因；我理解那些。我正在尋找導致它的事件，或者至少是在進行更改時。
引用將不勝感激。
有趣的是，看起來
bash實際上打算包括.，至少這是我對這個來源的閱讀（來自config-top.h）：/* The default value of the PATH variable. */ #ifndef DEFAULT_PATH_VALUE #define DEFAULT_PATH_VALUE \ "/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:." #endif（有些人質疑這個問題的相關性。有人談到Windows 上的許多可執行安裝程序容易受到類似攻擊：預設情況下，執行檔會
.在Downloads程式碼執行，通常是管理員。這是一個“不學習歷史的人注定要重蹈覆轍”的時刻。）
找到有關此決定的“歷史文件”並非易事，但引用 StackExchange 保護傘中的另一個答案，您會發現我也認為最適合您的問題的答案：避免“sh##發生”場景：
- bash：為什麼是 . 預設情況下不在路徑中？
問題：
多年來，在類 UNIX 系統（與我最相關的是 Linux）上，我注意到 . (目前目錄) 預設情況下從不在 $PATH 中。為什麼是這樣？我記得幾年前讀過它是一個安全問題，但我讀到的文章並沒有解釋究竟是什麼問題。是因為有人可能會在目錄中留下惡意版本的“ls”或“cp”，而我最終會在沒有意識到它的情況下執行它嗎？
回答：
您正確回答了自己的問題，這正是 dot 不在路徑中的原因：防止幼稚的病毒或誠實的錯誤。
當然，這是一個非常蹩腳且無用的防毒措施，沒有什麼能阻止你自己在路徑中添加點。
在這個連結上，你可以找到一個額外的例子，為什麼把點放在你的
$PATH.腳註：
一個極端的例子是普通使用者創建了一個shell腳本，例如
rm -r /，該腳本將刪除系統中該使用者具有寫入權限的所有文件和目錄，並將該腳本命名為ls。如果系統管理員導航到該腳本所在的目錄並嘗試執行標準ls命令以查看該目錄的內容，shell 將改為執行同名的腳本，從而刪除所有目前安裝在電腦上的分區！此外，PATH 的目的是以您不需要記住或鍵入二進製文件的完整路徑的方式完成命令的路徑。沒有必要為您所在目錄的命令建立索引。如果您知道這些程序的儲存位置，這根本沒有用。
編輯：
但是，經過一番研究，我發現搜尋路徑背後的想法來自Multics，但局限性在於它只在內部搜尋
/bin。Unix v3是第一個在沒有這個單目錄限制的情況下實現它的。並查看以下手冊的安全頁面，他們已經展示了.在 PATH 變數中使用時的問題。這不僅適用於su並且加強了在環境中註入惡意程式碼的安全問題。引用第 13 頁：
在 Morris 和 Fred Grampp 講述的正在進行的遊戲中發現了特洛伊木馬的技巧和對策。例如，請注意
login(1)第 8 章的刪除和 (Grampp, v8)/etc/概要的侵入。su這些小技巧打敗了留下命名login或su四處散佈的程序以希望擷取由粗心的系統管理員鍵入的密碼的舊栗子。 Modern 的其他細微特徵su：點被排除在 shell 搜尋路徑之外，竊賊最喜歡的 shell 變數IFS被重置。自構思以來，如果使用 dot 作為
$PATH.