在我的 native 应用程序中,我必须在本地网络上的另一台计算机上启动另一个应用程序 (toolB.exe)。为此,我使用 psexec 和对 _wsystem 的调用。现在,我正在尝试在同一台计算机上而不是在远程计算机上启动 toolB。所以在我的代码中我有这个:
const std::wstring command = L"\"" + psexecfull + L"\" " + psexecargs + L" -c -f -d -s -n 10 \"" + toolpathfull + L"\" " + toolargs;
int exitcode = _wsystem(nullptr);
wchar_t buffer[1024];
_wgetcwd(buffer, _countof(buffer));
exitcode = _wsystem(command.c_str());
这告诉我找到了命令解释器(第一次使用 nullptr 调用 _wsystem 返回 1),并且当前工作目录是 C:\project\bin\tools\toolA
,并且命令(C:\project\externals\psexec\tools\psexec.exe\\127.0.0.1 -c -f -d -s -n 10 C:\project\bin\tools\toolB\toolB.exe -arg
) 失败(使用命令第二次调用 _wsystem 返回 1 并且文本 The filename, directory name, or volume label syntax is incorrect
出现在我的应用程序控制台窗口中)。也许我还应该提到这段 native 代码在一个包含 C++( native )和 C++/CLI(托管)代码的 DLL 中,并由名为 toolA 的 .NET 应用程序(我认为在同一个 AppDomain 中)动态加载和执行.
但奇怪的是,当我从完全相同的工作目录手动执行完全相同的命令行时,psexec 运行正常并且 toolB.exe 按预期启动。那么为什么这不能通过调用 _wsystem 以编程方式工作?我该如何解决这个问题??
如果重要的话,我正在运行 Windows 7 x64。
最佳答案
好的,所以命令行上的手动尝试结果并不是完全相同的命令行文本,我没有为 psexec 和 toolB 可执行文件使用封闭的“”。为 psexec 可执行文件留下封闭的“”,所以显然 _wsystem 不能容忍用“”封闭第一个参数。这很奇怪,因为如果 psexec 位于带空格的路径中,则在尝试解析 psexec 路径时对 _wsystem 的调用将失败。我还不确定如何克服这个问题。
除此之外,对 _wsystem 的调用还返回了 toolB.exe 的进程 ID,而我期望为 0,但这是另一个问题。
关于c++ - 在调用 _wsystem 时执行 psexec 时出现问题,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/25916383/