为什么我不应该使用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的解决方案太慢）我将使用外部命令。