Skip to content
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

Join-Path error when installing Chocolatey as SYSTEM #1042

Closed
splatteredbits opened this issue Nov 8, 2016 · 10 comments
Closed

Join-Path error when installing Chocolatey as SYSTEM #1042

splatteredbits opened this issue Nov 8, 2016 · 10 comments

Comments

@splatteredbits
Copy link
Contributor

What You Are Seeing?

After installing Chocolatey as SYSTEM, $Global:Error has this error:

Join-Path : A positional parameter cannot be found that accepts argument 'chocolatey'.
At C:\Windows\TEMP\chocolatey\chocInstall\tools\chocolateysetup.psm1:198 char:27

+     $defaultInstallPath = Join-Path [Environment]::GetFolderPath(""CommonApplicat ...
+                           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

at Ensure-Permissions, C:\Windows\TEMP\chocolatey\chocInstall\tools\chocolateysetup.psm1: line 198
at Initialize-Chocolatey, C:\Windows\TEMP\chocolatey\chocInstall\tools\chocolateysetup.psm1: line 81
at <ScriptBlock>, C:\Windows\TEMP\chocolatey\chocInstall\tools\chocolateyInstall.ps1: line 16
at <ScriptBlock>, <No file>: line 194
at <ScriptBlock>, E:\Build\WhsInit\Initialize-Computer.ps1: line 183
at <ScriptBlock>, <No file>: line 1
    + CategoryInfo          : InvalidArgument: (:) [Join-Path], ParameterBindingException
    + FullyQualifiedErrorId : PositionalParameterNotFound,Microsoft.PowerShell.Commands.JoinPathCommand

Our unattended installer reports this as a failed install because of the error (it looks in $Global:Error).

When I look at the code, I see that this error is handled by a try/catch block. Unfortunately in PowerShell, caught exceptions are still populated in $Global:Error.

What is Expected?

I expect that handled errors won't appear in $Global:Error. Otherwise, how do I know if the installation failed or not?

How Did You Get This To Happen? (Steps to Reproduce)

  • Open PowerShell as SYSTEM: psexec -d -i -s powershell.exe
  • Run join-path [Environment]::GetFolderPath("CommonApplicationData") 'chocolatey'
  • Note the error.

If you assign the value of [Environment]::GetFolderPath("CommonApplicationData") to a variable, and join with that, you avoid the error, e.g.

$commonAppDataPath = [Environment]::GetFolderPath("CommonApplicationData")
join-path $commonAppDatPath 'chocolatey'

Or, wrap [Environment]::GetFolderPath("CommonApplicationData") with parenthesis:

join-path ([Environment]::GetFolderPath("CommonApplicationData")) 'chocolatey'
@ferventcoder
Copy link
Member

I expect that handled errors won't appear in $Global:Error. Otherwise, how do I know if the installation failed or not?

Typically the install exits with non-zero on a failure.

@ferventcoder
Copy link
Member

Or, wrap [Environment]::GetFolderPath("CommonApplicationData") with parenthesis

TIL

@ferventcoder
Copy link
Member

Out of curiosity, what happened to CommonApplicationData?

@splatteredbits
Copy link
Contributor Author

What do you mean?

@splatteredbits
Copy link
Contributor Author

Good to know about the non-zero exit code. That can help us determine if the Chocolatey install failed or not.

Unfortunately, that doesn't help our error reporting. We have a daily scheduled task that runs as SYSTEM on developer computers to keep them up-to-date. With our latest update, we are installing Chocolatey. We transcript the update/install process and use the number of errors as our flag to determine if something has gone wrong and notify our team when it has.

I'll put together a pull request to fix this issue.

@ferventcoder
Copy link
Member

@splatteredbits Do non-terminating errors get logged into $Global:Error? Perhaps you could make a determination of whether errors are terminating or not?

Although fixing these things would be helpful to not error.

@ferventcoder
Copy link
Member

What do you mean?

Why does CommonApplicationData evaluate to $null?

@teknowledgist
Copy link

teknowledgist commented Mar 13, 2017

Throwing my $.02 in here...

This is not a run-as-system problem. For whatever reason, Join-Path won't accept the special environment variables as a direct argument (i.e. not in ()). The same is true for split-path, but the error is different:

PS > [Environment]::GetFolderPath("desktop")
C:\Users\user\Desktop\

PS > join-path [Environment]::GetFolderPath("desktop") 'test'
Join-Path : A positional parameter cannot be found that accepts argument 'test'.
At line:1 char:10
+ join-path <<<<  [Environment]::GetFolderPath("desktop") 'test'
    + CategoryInfo          : InvalidArgument: (:) [Join-Path], ParameterBindingException
    + FullyQualifiedErrorId : PositionalParameterNotFound,Microsoft.PowerShell.Commands.JoinPathCommand

PS > split-path [Environment]::GetFolderPath("desktop")
Split-Path : Cannot convert 'System.String' to the type 'System.Management.Automation.SwitchParameter' required by para
meter 'Qualifier'.
At line:1 char:11
+ split-path <<<<  [Environment]::GetFolderPath("desktop")
    + CategoryInfo          : InvalidArgument: (:) [Split-Path], ParameterBindingException
    + FullyQualifiedErrorId : CannotConvertArgument,Microsoft.PowerShell.Commands.SplitPathCommand

PS > join-path ([Environment]::GetFolderPath("desktop")) 'test'
C:\Users\user\Desktop\test

At least it should be an easy fix.

@ferventcoder
Copy link
Member

ferventcoder commented Mar 13, 2017

@teknowledgist yes, and it's already completed in a PR. #1045.

ferventcoder pushed a commit that referenced this issue Mar 15, 2017
PowerShell sees the return value from [Environment]::GetFolderPath as multiple parameters.
ferventcoder added a commit that referenced this issue Mar 15, 2017
* pr1045:
  (GH-1042) Ensure-Permissions fails when run as SYSTEM
ferventcoder added a commit that referenced this issue Mar 15, 2017
* stable:
  (GH-1042) Ensure-Permissions fails when run as SYSTEM
  (build) ensure build is on .NET 4.0
  (maint) remove test console logging
  (maint) rename searchTerm variable
  (maint) update nuget.core
  (GH-1059) Fix: Unable to change command execution timeout
  (GH-1059) Clean up commandExecutionTimeout setting
  (maint) clean up CacheLocation
  (GH-1202) Allow 0 for infinite timeout
  (GH-1059) Deprecate old config elements
@ferventcoder
Copy link
Member

Closed with 3571604

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants