為什么我不應該使用php的unix命令？

Question

你為什么不想在php中通過exec()繼續使用bash命令？

我不考慮可移植性問題（我肯定不會將其移植到Windows上運行）。 這只是編寫腳本的好方法。

一方面：

1. 我需要在php中編寫更多行，然后在bash中完成相同的任務。 例如，當我需要過濾文件中的某些行時，我無法使用某些內容而不是cat file | grep string > new_file成像 cat file | grep string > new_file 。 這需要花費更多的時間和精力在php中完成。
2. 當出現問題時，我不想分析所有情況。 我將向用戶顯示bash命令輸出，因此他會知道究竟發生了什么。
3. 我不需要在文件系統函數周圍編寫另一個包裝器並使用它。 利用操作系統進行文件搜索，操作等更有效。

另一方面：

1. 在大多數情況下，使用exec()調用unix命令可能效率低下。 產生一個單獨的過程是非常昂貴的。 不是在談論在apache下運行的腳本，這甚至比從命令行腳本產生的效率低得多。
2. 有時它被證明是“黑魔法般的”和類似perl的腳本。 雖然可以通過詳細的評論來避免。
3. 也許我只是想在他們不應該的時候一起使用兩種不同的工具。 每個工具都有自己的應用程序，不應混合在一起。
4. 即使我確定用戶不會嘗試運行腳本會出現惡意目的，使用exec()是一種潛在的安全威脅。 在大多數情況下，用戶數據可以使用escapeshellarg()進行轉義，但這仍然是一個需要考慮的問題。

Answer 1

避免這種情況的另一個原因是，創建這樣的安全漏洞要容易得多。 例如，如果用戶設法潛行

`rm -rf /`

（使用反引號）進入輸入，你的bash代碼可能實際上是服務器的核心（或者至少是核武器）。

這大多是宗教事物，大多數開發人員都試圖編寫始終有效的代碼。 依賴外部命令是在某些系統上（甚至在相同的操作系統上）使代碼失敗的可靠方法。

Answer 2

你想要實現什么目標？ PHP具有基於正則表達式的函數，可以從文件中查找所需內容。 是的，您可能需要大約5行代碼來完成它，但它可能不會更高或更低效。

反對在PHP中使用exec（）的主要原因是為了安全。 如果您信任您的用戶在bash中向您發出exec（）命令，他們可以輕松地運行惡意命令，例如安裝和啟動后門特洛伊木馬程序，刪除文件等。

只要你小心（使用shell轉義命令來清理用戶輸入，限制Apache用戶權限等），它應該不是問題。 我現在只是在一個完整的平台上工作，它依賴於前端執行shell進程，因為C ++比PHP快得多，所以我編寫了很多后端邏輯作為shell應用程序並保留PHP對於前端邏輯。

Answer 3

即使你說便攜性不是問題，你也永遠不知道未來會怎樣，所以我鼓勵你重新考慮這個立場。 例如，我曾被要求將一個由Unix編寫的編輯器（由其他人編寫）移植到DOS。 原始程序預計不會被移植，而是使用深深嵌入代碼中的Unix特定調用編寫。 在審查了所需的工作量之后，我們放棄了這項任務太費時間。

我在PHP中使用過exec調用; 但是，我沒有其他辦法可以完成我需要的東西（我不得不稱另一種用另一種語言編寫的程序，而且語言之間沒有其他橋梁）。 然而，IMO，exec調用不必要是丑陋的。 正如其他人所說，他們也可能產生安全風險並減慢您的計划速度。

正如你自己所說，你需要很好地記錄exec調用，以確保程序員能夠理解它們。 為什么要創造額外的工作？ 不僅是現在，而且將來，當需要記錄對exec調用的任何更改時。

最后，我建議你學習PHP及其功能更好一點。 我對PHP不是那么好，但是在谷歌和php.net的短短幾分鍾內，我想我完成了你給出的一個例子：

$search_results = preg_grep($search_string, file($file_name));
foreach ($search_results as $result) {
    echo $result . "\n";
}

是的，這是更多的代碼，但不是那么多，你可以把它放在一個函數中，如果合適的話......如果一個PHP大師可以縮短它，我也不會感到驚訝。

Answer 4

恕我直言，使用exec（）通過PHP執行* nix命令的主要問題是安全性，而不僅僅是性能甚至代碼風格。

如果你有一個非常好的輸入清理（這很難實現），你可能不會有任何安全漏洞。

Answer 5

就個人而言，如果可移植性不是問題，我會完全使用* nix命令，如grep，locate等，而不是試圖在PHP中復制該功能。

這是關於使用最好的工具來完成工作。 在某些情況下，可以說比大多數人意識到的更頻繁，利用操作系統進行文件搜索，操作等等（其中包括）

Answer 6

即使提到使用exec，很多人也會喜歡上大量的磚塊。 有些人會認為是褻瀆，但不是我。 如果您的服務器配置正確，我可以看到exec在某些情況下沒有任何問題。 但缺點是你正在產生另一個進程。

Answer 7

如果使用Web服務器運行PHP，則運行該腳本的“用戶”可能無權運行某些shell命令。 你說可移植性不是問題，但我可以向你保證這是一個問題，（除非你是為了好玩而創建PHP腳本）。 在事物和條件變化很快的商業世界中，您不會知道有一天您可能需要在其他平台上運行腳本。

Answer 8

php不是一個好的執行者。 php從apache生成一個進程，如果該進程掛起，如果你的站點也運行在同一個apache上，你的apache服務器將掛起; 它會失敗。

你可能會遇到像這樣的愚蠢問題，如果它發生你甚至無法重啟apache而不從shell手動殺死衍生進程。

http://bugs.php.net/bug.php?id=38915

因此，我不是在談論安全性，從php運行linux命令失敗超過你的想法，使用exec的最糟糕的部分，並不總是可以將錯誤消息發送回php。 或編寫取決於exec發生的事情的后續方法。

考慮這個偽示例：

exec ('bash myscript.sh',$x)
if (myScriptWasOk == true) then do this

你沒有辦法讓'myScriptWasOk'變量正確。 你只是對它一無所知，有時候$ x會幫助你。

所有這些都說，如果你需要一些簡單的東西，如果你測試了你的腳本並且它工作正常，那就去吧。

Answer 9

除非您采取極端預防措施以確保執行代碼的人員無法使用它，否則它是不安全的。

Answer 10

如果你的目標只是兼容Unix（這完全沒問題），我看不出它有什么問題。 今天幾乎可用的服務器操作系統是Unix克隆，當然除了Windows之外我認為首先用作服務器平台是荒謬的（我在這里談論經驗，這不僅僅是微軟的仇恨）。 在我看來，Unix兼容性是任何服務器上完全合法的要求。

我能看到避免它的唯一真正原因是性能。 您將很快發現執行外部進程通常非常慢。 它在C中很慢，而且在PHP中很慢。 我認為這是最大的真正的非宗教問題。

編輯：哦，至於安全問題，這是一個簡單的事情，確保您完全控制傳遞給操作系統的變量。 無論如何，在進程和語言之間進行通信時，您必須要考慮這一點，例如，當您執行SQL查詢時。 在我看來，這並不足以讓我不做某事，這只是在這種情況下必須考慮的事情，就像在每種情況下一樣。

Answer 11

如果可移植性確實不是問題，因為您正在構建一個始終位於您自己的完全受控服務器上的公司解決方案，我會說您可以根據需要選擇shell命令。 只要您使用escapeshellarg（）和consorts進行適當的基本衛生設施，就沒有固有的安全問題。

與此同時，在我的項目中，可移植性主要是一個問題，當它出現時，我嘗試根本不使用shell命令 - 只有在PHP根本無法完成某些事情時（例如MP3解碼/編碼，ImageMagick，視頻操作）或不合理（即基於PHP的解決方案太慢）我將使用外部命令。