Util.getWinDirs throws an exception if PowerShell is in Constrained Language Mode

If PowerShell is in Constrained Language Mode, that is PS C:\> $ExecutionContext.SessionState.LanguageMode prints ConstrainedLanguage instead of FullLanguage, Util.getWinDirs throws an exception which can be observed by running dev.dirs.DirectoriesTest:

sbt:directories> testOnly dev.dirs.DirectoriesTest
[info] Total time: 0 sec
[info] Compiling 1 Java source to C:\Project\prj\directories-jvm\target\test-classes ...
[error] Test dev.dirs.DirectoriesTest.testBaseDirectories failed: java.lang.RuntimeException: Couldn't find pwsh.exe or powershell.exe on path or in default system locations, took 2.545 sec
[error]     at dev.dirs.Util.windowsFallback(Util.java:280)
[error]     at dev.dirs.Util.getWinDirs(Util.java:161)
[error]     at dev.dirs.BaseDirectories.<init>(BaseDirectories.java:274)
[error]     at dev.dirs.BaseDirectories.get(BaseDirectories.java:246)
[error]     at dev.dirs.DirectoriesTest.testBaseDirectories(DirectoriesTest.java:9)
[error]     ...
[error] Caused by: java.io.IOException: no output from process
[error]     at dev.dirs.Util.runCommands(Util.java:206)
[error]     at dev.dirs.Util.runWinCommands(Util.java:241)
[error]     at dev.dirs.Util.windowsFallback(Util.java:278)
[error]     ... 41 more
[error] Failed: Total 1, Failed 1, Errors 0, Passed 0
[error] Failed tests:
[error]         dev.dirs.DirectoriesTest
[info] Total time: 3 sec
[info]   root / Test / testOnly: 3 sec
[error] (Test / testOnly) sbt.TestsFailedException: Tests unsuccessful
[error] Total time: 3 s, completed 19.11.2020 14:08:57

The inner exception java.io.IOException: no output from process is thrown because the PowerShell process exits with only printing to stderr and nothing to stdout.

PowerShell exits with errors when trying to execute the SCRIPT_START_BASE64 script. The error can be reproduced in a PowerShell console by executing the first line of that script:

PS C:\> $ExecutionContext.SessionState.LanguageMode
FullLanguage
PS C:\> [Console]::OutputEncoding = [System.Text.Encoding]::UTF8

PS C:\> $ExecutionContext.SessionState.LanguageMode = "ConstrainedLanguage"

PS C:\> $ExecutionContext.SessionState.LanguageMode
ConstrainedLanguage
PS C:\> [Console]::OutputEncoding = [System.Text.Encoding]::UTF8
Die Eigenschaft kann nicht festgelegt werden. Das Festlegen der Eigenschaft wird in diesem Sprachmodus nur für Kerntypen unterstützt.
In Zeile:1 Zeichen:1
+ [Console]::OutputEncoding = [System.Text.Encoding]::UTF8
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [], RuntimeException
    + FullyQualifiedErrorId : PropertySetterNotSupportedInConstrainedLanguage

Note that [Console]::OutputEncoding = [System.Text.Encoding]::UTF8 does not exit with an error in FullLanguage mode.

That Util.getWinDirs throws an exception if PowerShell is in Constrained Language Mode is the reason why the current sbt 1.4 versions are not usable in such environments as noted in https://github.com/dirs-dev/directories-jvm/pull/40#issuecomment-729581072 and https://github.com/coursier/coursier/issues/1913.

A possible workaround to make sbt usable again would be removing this line.

[fthomas]

FTR: sbt 1.4.6 is now using directories-jvm 23 via lm-coursier 2.0.5 / Coursier 2.0.8 and the fix with dowgrading the PowerShell version (https://github.com/dirs-dev/directories-jvm/commit/f976091da250fe3a85ca48df6041cf9852f79a09) seems to be working:

PS C:\> $ExecutionContext.SessionState.LanguageMode
ConstrainedLanguage
PS C:\> sbt csrCacheDirectory
...
[info] csrCacheDirectory
[info]  C:\Users\...\AppData\Local\Coursier\cache\v1

I can finally enjoy sbt 1.4 on Windows. Thanks @soc, @kalejami, @eed3si9n and @alexarchambault for fixing this issue and getting it into sbt!

[eed3si9n]

There’s some discussion about environment variables in this thread - https://github.com/dirs-dev/directories-jvm/issues/26#issuecomment-570288952

In my opinion, the majority of the sbt users would be happy as long as directories-jvm reliably returned any value, and it doesn’t really have to be Apple/Microsoft/freedesktop compliant. I mean it would be nice if the value was correct in some sense, but for the sake of downloading JARs in some CI box on Windows etc, erroring out because Powershell or whatever is many times worse outcome than directories-jvm falling back to some stable made-up value.

For that I think we should consider the 3-step strategy:

1. On Windows, try environment variable first. If it’s there, no need to deal with powershell. Great.
2. If the environment variable is missing, only then try powershell, catch any errors, and print them out in the stderr.
3. If powershell bailed, use some hard-coded reasonable fallback.