Win7 runas命令:如何捕获运行命令的输出?

发布于 2024-08-05 09:39:14 字数 503 浏览 4 评论 0原文

我正在尝试(在 Windows 7 下)使用 runas 命令停止然后重新启动服务。 (Win7 需要管理员权限才能执行此操作;因此需要使用 runas。)

停止该服务可以正常工作,但启动它却不行。这是我用来停止服务的命令:

runas /user:myDomain\myUserId "net stop serviceName"

这是启动服务的命令:

runas /user:myDomain\myUserId "net start serviceName"

当我运行上述命令时,另一个命令窗口会打开,但在我看到其中的任何内容之前就闪烁了;因此我不知道出了什么问题。

所以,我的问题是:当通过 runas 运行时,如何从 net start 命令捕获 stdout 和/或 stderr?我尝试过仅使用重定向,但只得到一个空文件。另一种解决方案是让 runas 打开窗口以使子任务保持打开状态。

提前致谢。

I'm trying (under Windows 7) to use the runas command to stop then restart a service. (Win7 requires admin privs to do this; thus the use of runas.)

Stopping the service works fine, but starting it does not. Here's the command I'm using for stopping the service:

runas /user:myDomain\myUserId "net stop serviceName"

Here's the command for starting the service:

runas /user:myDomain\myUserId "net start serviceName"

When I run the above command another command window opens, but flashes away before I can see anything in it; thus I have no idea what's going wrong.

So, my question is: How might I capture stdout and/or stderr from the net start command when run via runas? I've tried just using redirection but just get an empty file. Another solution would be to get the window opened by runas for the subtask to remain open.

Thanks in advance.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

别低头,皇冠会掉 2024-08-12 09:39:14

使用要运行的命令启动 cmd.exe,并指定将输出写入文件。

runas /user:myDomain\myUserId "cmd.exe /c net stop serviceName > output.txt"

您可以使用 2>用于网络停止的错误输出。

Launch cmd.exe instead with the command to run, and specify that the output be written to a file.

runas /user:myDomain\myUserId "cmd.exe /c net stop serviceName > output.txt"

You can use 2> for error output from net stop.

迷离° 2024-08-12 09:39:14

另外,如果您不想处理输出文件,可以使用 cmd.exe /k 而不是 /c 来启动命令,它将为您打开会话窗口。如果您只是想快速浏览一下,可能会更容易/更快。

Also, if you don't want to bother with the output file, you can use cmd.exe /k instead of /c to launch the command and it will leave the session window open for you. Might be easier/quicker if you just want a quick peek.

暮光沉寂 2024-08-12 09:39:14

尝试 gsudo 并运行命令:

gsudo net stop serviceName

Try gsudo and run the command:

gsudo net stop serviceName
热血少△年 2024-08-12 09:39:14

我发现这是一个非常古老的问题,但我发现最近有关​​于该主题的活动。由于我在使用 Windows 命令行的“runas”命令时也遇到过这个问题,因此我想分享我的首选解决方案并解释一些需要看似复杂的方法的麻烦。

首先,如果我们使用 Michael 和 SOME GUY 提到的新命令解释器 shell 调用命令,我们可以通过使用 runas 命令执行命令来捕获标准输出和标准错误流的结果。

我希望添加答案,因为在我的用例中,我正在运行一个非常相似的命令作为自动化例程的一部分,并且我不希望窗口窃取焦点(如“模式”窗口那样),也不希望窗口顺便说一句,但我确实希望有一个小的视觉队列,任务已经运行,结果正在等待审查和驳回。为了解决这个问题,我做了

runas /savecred /user:myDomain\myUserId "cmd /C start /MIN cmd /C """net stop serviceName ^& timeout 1800""" "

这个方法,当我制定这个方法时,有一些小问题给我带来了很大的痛苦:

  1. 需要使用启动命令,以便我可以运行命令 MINIMIZED ,以便模态命令控制台不会窃取焦点。只有启动命令允许命令在最小化窗口中运行(纯命令控制台方法,不包括 PowerShell、WMI/WBEM/CMI 或脚本(VBS 或 WindowsScript,无论是调用 cscript 还是 wscript)

  2. 启动命令是命令行解释器的一部分(因此,我必须调用两个命令 shell——一个用于运行启动命令,另一个用于运行我们希望在命令控制台中捕获其输出的命令)。不是一个文件,即使只是暂时的,正如我所展示的。

  3. 与非常相似的 start 和 cmd 命令不同,runas 命令总是需要引号,这也让我想到了纯命令行方法的第四个怪癖......

  4. runas 命令的带引号的字符串必须使用脱字符而不是反斜杠转义字符。一个例外是双引号,它可以转义为三个双引号(使命令相当难以阅读)。

它不是一个非常优雅的解决方案,也不适合大量用例,但我发现它对于从帐户运行自动化非常有用,我有时也做其他事情。通过这种方式,我可以将家用电脑上的帐户保持在最低限度,但我可以运行脚本化的自动化任务,而不必过度依赖 Windows Scheduler,Windows Scheduler 有自己的一些怪癖,尤其是即时标准输出流和标准错误你和我想要的流(至少在没有配置的情况下,我们可以回到本质上相同的方法)。

我希望这可以帮助人们避免一些挫折,尽管在 PowerShell 很快取代过时的命令控制台的时代,它可能不会。没关系。由于与轻得多的命令控制台相比,PowerShell 具有异常大的词汇和语法,因此我认为命令控制台至少还剩下一点生命。

I see this is a very old question, but I see there has been recent activity on the topic. Since this is an issue I too have experienced with the "runas" command of Windows command line, I wanted to share my preferred solution and explain some of the nuasances that necessitate the seemingly convoluted approach.

First off, we can capture the results from the standard output and standard error streams from executing the command with the runas command if we invoke the command with a new command interpretter shell as mentioned by Michael and SOME GUY.

I wish to add to the answer since in my use case, I was running a very similar command as part of an automated routine, and I did not want the window stealing focus (as "modal" windows do) nor did I want the window in the way, but I did wish to have a small visual queue the task had run and the results were awaiting being reviewed and dismissed. To solve this I did

runas /savecred /user:myDomain\myUserId "cmd /C start /MIN cmd /C """net stop serviceName ^& timeout 1800""" "

There are a few nuasnaces to the approach that caused me a great deal of grief as I formulated this approach:

  1. The use of the start command is desired so that I can run the command MINIMIZED so the modal command console will not steal focus. Only the start command allows the command to run in a minimized window (of purely command console approaches not inclusive of PowerShell, WMI/WBEM/CMI or scripts (VBS or WindowsScript, be it cscript or wscript invoked)

  2. The start command is part of the command line interpretter (compiled into the command shell). I, therefore, have to invoke two command shells -- one to run the start command and a second to run the command whose output we wish to capture in a command console and not a file, even if only temporarily as I have shown.

  3. Unlike the very similar start and cmd commands, the runas command always requires quotes which also brings me to a 4th quirkiness of the purely command line approach...

  4. The quoted string for the runas command must escape characters with carets and not backslash. An exception is double quotes which can be escaped as triple double quotes (making commands rather difficult to read).

It isn't a very elogant solution and isn't suitable for a large number of use cases, but I found it very useful for running automation from an account I also sometimes do other things. In this manner, I can keep accounts to a minimum on my home PC and yet I can run scripted automated tasks without an ultra reliance on Windows Scheduler which has had some quirks of its own, but especially the immediate standard output stream and a standard error streams that you and I desire (at least not without configurations that land us right back at essentially this same approach).

I hope this helps save someone some frustrations down the road though in an era when PowerShell is very quickly replacing the antiquated command console, it may not. That's ok. Since PowerShell has an exceptionally large vocabulary and syntax compared to the considerably lighter command console, I think the command console has at least a little life still left in it.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文