-
-
Notifications
You must be signed in to change notification settings - Fork 129
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issue: Setting PowerShell's location to any provider other than FileSystem is not supported. #124
Comments
I did test with I used Debug: Command to run: "C:\Program Files\PowerShell\7\pwsh.exe" -NoLogo -NoProfile -Command "pwsh -workingdirectory \"HKLM:\SOFTWARE\WOW6432Node\Cisco\Cisco AnyConnect Secure Mobility Client\\\" -c \"get-itemproperty .\""
Debug: Using Console mode TokenSwitch
Debug: CreateProcessAsUser: "C:\Program Files\PowerShell\7\pwsh.exe" -NoLogo -NoProfile -Command "pwsh -workingdirectory \"HKLM:\SOFTWARE\WOW6432Node\Cisco\Cisco AnyConnect Secure Mobility Client\\\" -c \"get-itemproperty .\""
Debug: Elevating process: C:\ProgramData\chocolatey\lib\gsudo\bin\gsudo.exe --debug gsudoelevate --pid 22604
Debug: Elevated instance started.
VPNClientInstalled : 1
InstallPathWithSlash : C:\Program Files (x86)\Cisco\Cisco AnyConnect Secure Mobility Client\
Full Install : on
SuppressModalDialogs : 1
PSPath : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Cisco\Cisco AnyConnect Secure Mobility Client\
PSParentPath : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Cisco
PSChildName : Cisco AnyConnect Secure Mobility Client
PSDrive : HKLM
PSProvider : Microsoft.PowerShell.Core\Registry
Debug: Process exited with code 0 |
Hi Matt.
No, it is a problem on the
Reasonable, yes. Posible? Not so much. Powershell's ability to set the "current location" to something other than a file system folder is a PowerShell fabrication, not something supported by the operating system itself. If gsudo were a native powershell command (or had a native ps1 wrapper #39), there would be more options available. In a nutshell, gsudo can't know what powershell's Get-Location is. It only knows And AFAICT, can't be fixed, unless we dive into #39. Workarounds:
Sorry. |
ItemProperty
Cmdlets Have Wrong Path
Ah, I see. Thanks for the robust explanation! Very enlightening. I had looked at Issue #39. It would be awesome to get that going more so. On kind of a different note sparked from reading the docs, it would be cool if gsudo could return the clixml using the Anyway, love the project. Thanks for the help. Feel free to close the Issue or I'll close if you have anything more to add. |
I've tried it, but powershell does not deserealizes the results automatically: (For faster testing, I am using
which means, the user can not simply
and this syntax is awfull, and I can't do anything inside
Now it should be time to focus on #39. There is experimental Invoke-gsudo.ps1, file which should be on the path, that allows you to do things like:
There is room in Invoke-gsudo.ps1 to handle Set-Location to any location other than FileSystem-based. I will try to get back into #39 and make it move forward soon. |
I gotcha. That is unfortunate and ugly syntax. Thanks for the work on the PS function! I was playing with it a little. It was weird that setting the below to a variable actually invokes the serialization on So the below returns the raw
while the below holds the deserialized object. It is like in the setting to a variable the serialization is forced to happen.
I was also playing with the below.
It returned an error though. I guess that's why you had to add a PSMessageDetails :
Exception : System.Management.Automation.MethodInvocationException: Exception calling "Deserialize" with "1" argument(s): "Data at the root level is invalid.
Line 1, position 1."
---> System.Xml.XmlException: Data at the root level is invalid. Line 1, position 1.
at System.Xml.XmlTextReaderImpl.Throw(Exception e)
at System.Xml.XmlTextReaderImpl.Throw(String res, String arg)
at System.Xml.XmlTextReaderImpl.ParseRootLevelWhitespace()
at System.Xml.XmlTextReaderImpl.ParseDocumentContent()
at System.Management.Automation.Deserializer.Start()
at System.Management.Automation.Deserializer..ctor(XmlReader reader, DeserializationContext context)
at System.Management.Automation.PSSerializer.DeserializeAsList(String source)
at System.Management.Automation.PSSerializer.Deserialize(String source)
at CallSite.Target(Closure , CallSite , Type , String )
--- End of inner exception stack trace ---
at System.Management.Automation.ExceptionHandlingOps.ConvertToMethodInvocationException(Exception exception, Type typeToThrow, String
methodName, Int32 numArgs, MemberInfo memberInfo)
at CallSite.Target(Closure , CallSite , Type , String )
at System.Dynamic.UpdateDelegates.UpdateAndExecute2[T0,T1,TRet](CallSite site, T0 arg0, T1 arg1)
at System.Management.Automation.Interpreter.DynamicInstruction`3.Run(InterpretedFrame frame)
at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
TargetObject :
CategoryInfo : NotSpecified: (:) [], MethodInvocationException
FullyQualifiedErrorId : XmlException
ErrorDetails :
InvocationInfo : System.Management.Automation.InvocationInfo
ScriptStackTrace : at <ScriptBlock>, <No file>: line 1
PipelineIterationInfo : {} I see now a little bit that there is a difference between the Thanks for the discussion and help. I appreciate the long responses. EDIT 1: I see a little more now. In the output, when it has |
I think I prefer if you could experiment with 'Invoke-gsudo.ps1' where I've already worked thru several issues. I've just pushed a new version. I will announce it as open-for-testing on #39, but i'm delayed in an eternal loop of testing / debugging / and powershell A-ha moments. For example for some reason
In a nutshell, my goal is that Invoke-gsudo behaves as similar as possible to Invoke-Command (but elevated). Obviously will never be equal since Invoke-gsudo runs in a different scope / process. I hope you get what I mean. If you are open to experimentation, please grab it and place it on gsudo's folder. Let me know how it goes. BTW, |
Excellent! That is awesome! I'll continue to test the |
Hey, since you brought the dotsource idea, let me ask you a big question. This is my first time releasing powershell code to the public, and I'm definitely not familiar on how to 'package' it. Releasing gsudo is automated but still hard because it needs testing for scoop / chocolatey / winget .MSI / manual installation / etc. Testing fresh install, upgrading from diferent versions... So I wanted to keep the 'deployment model' for this Powershell function as simple as possible.
I settled with the current approach... so let me ask... Did you had to wrap the .ps1 content with Do you imagine any other way of releasing a Invoke-gsudo function (easiest as possible to implement on all package managers)? Thanks! |
Yeah I see what you mean now that I'm thinking about it more. I was quickly trying to incorporate it into my OhMyPosh deploys a dual approach on Users don't come to your application through the PSGallery anyway. If there was a module, I could see it as a separate repo where the underlying code is deployed as a library that a Powershell module could use instead of calling the All that being considered, I think the approach you have outlined is the best. I copied your recent build into my |
Hi Matt, The idea of maybe of adding an additional Regarding features that the module could have:
I'm thinking out loud here. BTW, |
Oh yeah, I like the idea of having the I would think it should replace the If you wanted to have both, I would think some type of Other examples include: Now the features you mentioned are very interesting. I didn't even know about the I like the idea of the proxy command for For Lastly, I do like the idea of the users generating their own alias. I would think many PowerShell users would import the module and then alias the |
Issue Description
Both
gsudo
andsudo
won't handle the Registry Provider path when using the dot notation (.
) for$PWD
. Execution places me in my previous FileSystem provider directory instead of the current Registry Provider Directory such asHKLM:
So when usingGet-ItemProperty
I return aFileInfo
object of previous FileSystem Provider and when usingSet-ItemProperty
pwsh.exe
throws an error.Steps to Reproduce
pwsh.exe
Set-Location $HOME
Set-Location HKLM:\SOFTWARE
sudo Get-ItemProperty -Path .
Workaround
I pass
$PWD.Path
instead of the period.Additionally, after typing this up I am noticing it is most likely a
powershell
issue? I looked quickly and couldn't find an article or Issue surrounding it.Screenshots
--debug Output
Context:
Windows 10 Version 1909 ( OS Build 18363.1377 )
gsudo v1.0.2 (Branch.master.Sha.cab27ed3ca23496129320dfed56624274c9a27a6)
The text was updated successfully, but these errors were encountered: