通过shell运行程序

我正在运行Windows 7×64和Excel 2010×32。 我使用ExecCmd（一个等待命令提示符进程完成的Microsoft函数）通过​​vba调用32位dos程序（用Fortran编写）。 我向这个函数发送一个命令行，它明确包含程序path以及input文件和输出文件的path。

这在我的电脑上以及运行相同软件（OS和Office）的公司PC上运行良好，并且我可以一般访问C：驱动器。

在其他公司的PC上，如果没有一般的C：驱动器访问权限，这是行不通的 – 也就是说，dos程序不会生成输出文件。 在这些PC上，我仍然可以手动在命令提示符下运行程序。 只是调用这个命令提示符不能通过Excel VBA工作。

现在奇怪的是，我可以通过在命令行开头添加“cmd.exe / c”来成功运行这些程序之一。 这似乎是在命令提示符（！）内运行命令提示符。 另一个程序（顺便说一下，这个程序比较大）在这些PC上通过vba完全不起作用。 我需要能够为其他员工提供有用的东西。

任何人都可以点亮这里发生的事情，并build议解决？ 我可以通过一些代码，但我认为上述应该是自我解释。

Answer 1

您将命令shell与控制台窗口混淆。 在这种情况下，这一区别至关重要。

控制台模式程序（又名“命令行程序”）需要一个控制台窗口来提供input和输出。 从GUI程序启动控制台模式程序时，Windows将自动为其创build控制台窗口（除非另有说明）。

命令shell（又名“命令提示符”）是cmd.exe ，一个控制台模式程序。

这里重要的一点是并不是每个控制台窗口都有一个运行cmd.exe的实例。 从GUI程序启动控制台模式程序时，Windows会自动创build控制台窗口，但不会自动创buildcmd.exe的实例。 如果你想传递一个命令到cmd.exe你必须自己做，或者使用一个运行库例程来为你做。

ExecCmd不这样做; 它直接运行程序。 因此，将cmd /c <command>传递给ExecCmd并不是“在命令提示符下运行命令提示符”。 没有cmd /c你没有运行命令shell命令，你只是启动一个可执行文件。

有多种原因让你传递的命令可能需要被赋予命令行。 例如：

• 它可能是一个像dir或type这样的内置命令，它只存在于命令shell中;

• 它可能包括redirect或stream水线操作符或环境variablesreplace;

• 它可能是一个脚本，而不是一个可执行文件。

还有其他的情况。 如果向我们显示传递给ExecCmd的命令行，我们可能会提供更具体的build议。 （相同的命令行显然在某些机器上工作的事实令人费解，但是如果没有更多的信息就不能解决。