使用Start-Process
,当使用Verb
时,Workingdirectory
选项不起作用,新的powershell总是从开始C:\WINDOWS\system32
。为什么是这样?如果没有额外的 cd
命令,我该如何做到这一点?
PS C:\> $PSVersionTable
Name Value
---- -----
PSVersion 5.1.14393.0
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.14393.0
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
PS C:\> Start-Process -FilePath powershell.exe -Verb Runas -WorkingDirectory C:\ws\
# the new ps shell always in system32:
Windows PowerShell
Copyright (C) 2016 Microsoft Corporation. All rights reserved.
PS C:\WINDOWS\system32> pwd
Path
----
C:\WINDOWS\system32
最佳答案
至于为什么 - 请参阅此答案的底部。
至于有效的解决方法(但是,它需要使用 cd
( Set-Location
)):
Start-Process -FilePath powershell.exe -Verb Runas `
-ArgumentList '-NoExit -Command "cd C:\ws"'
为避免引号麻烦,您还可以单独传递参数,命令字符串本身除外:
Start-Process -FilePath powershell.exe -Verb Runas `
-ArgumentList '-NoExit', '-Command', 'cd C:\ws'
Venryx指出,如果您想将此技术应用于调用通常使用 -File
调用的脚本文件而不是 -Command
, 你必须切换到 -Command
首先更改位置然后 (;
) 调用 (&
) 脚本 script.ps1
的方法(假设两个参数不能组合)在新位置,这个例子:
Start-Process -FilePath powershell.exe -Verb Runas `
-ArgumentList '-Command', 'cd C:\ws; & .\script.ps1'
有关嵌套引用的更复杂示例,请参阅 this answer .
在实践中 - 和 docs do not mention that - -WorkingDirectory
如果您启动进程 提升(具有管理权限,这就是 -Verb RunAs
- 有点晦涩 - 所做的),参数不被尊重:位置默认为 $env:SYSTEMROOT\system32
(通常为 C:\Windows\System32
)。
请注意,这不是 -Verb
参数本身就是问题所在,但它的具体RunAs
争论。
唯一 情况下 -WorkingDirectory
与 -Verb RunAs
相结合受到尊重如果正在启动的程序是 PowerShell Core,即 pwsh.exe
- 无论您是从 Windows PowerShell 还是 PowerShell Core 调用。
这种行为是否有充分的技术原因,或者这是否是一个错误,我不知道。 如果您这样做,请告诉我们。
在所有其他情况下:
按原样以当前用户身份运行(默认)
使用
-Verb RunAsUser
模拟不同的用户(始终带有交互式凭据提示)使用
-Credential <PSCredential>
以不同的用户非交互方式运行
-WorkingDirectory
参数 被 尊重。
但是,如果(不同的)目标用户缺乏访问隐含(当前位置)或明确指定的工作目录(通过 -WorkingDirectory
)的权限,则当前位置默认为 C:\
在情况 (2) 中,导致 Start-Process
的失败案例 (3) 中的命令。
关于powershell - 使用动词时工作目录不起作用,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/38711252/