问题
$PSVersionTable output is
Name Value
---- -----
PSVersion 5.1.18362.628
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.18362.628
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
[System.Environment]::OSVersion.Version output is
Major Minor Build Revision
----- ----- ----- --------
10 0 18363 0
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe started as a user who is a member of the local administrator's group, but not in elevated mode. Call this the 'parent' console.
In the parent console, execute (where 'UserName' should be replaced by either the same or a different user logged-in interactively to the computer)
Start-Process -FilePath powershell.exe -Credential UserName
Upon entering the correct password for 'UserName', a new PowerShell window opens (let's call this the 'child' console). Within that, type 'exit' and then hit the Enter/Return key. Nothing happens in the child console: no letters appear, the Enter/Return is not processed.
Switch to the parent console, press the space bar four times. As the space bar is pressed, 'exit' will appear in the child console. Pressing the space bar one more time will cause the 'Enter/Return' key to be processed in the child and it will then exit.
I've tried this on another machine running a 2016 version (10.0 build 14393) of Win 10 with the same results.
This doesn't seem right. Is it right? If it is, how do I avoid it?
Thank you.
回答1:
This doesn't seem right. Is it right?
No, it's a long-standing bug, still present as of PowerShell 7.0, unfortunately; it has been reported in this GitHub issue.
JosefZ narrowed things down in a comment:
It seems that both processes (created via described procedure) are blocking keyboard input mutually. If I use the
-Wait
switch, then at least the child process accepts keyboard input…
how do I avoid it?
The workaround is to use the standard runas.exe utility:
runas /user:UserName powershell.exe
Caveat: As you point out, the HOMEPATH
(and presumably also HOMEDRIVE
) environment variable isn't set correctly in the new session (as of Windows 10, version 1909): HOMEPATH
unexpectedly points to \WINDOWS\system32
rather than the user's home path; by contrast, USERPROFILE
does contain the expected value.
来源:https://stackoverflow.com/questions/60676418/parent-powershell-console-seems-to-control-child-powershell-console-i-o