Failure on Windows

[ndmitchell]

If I change ghcide to have a different Stack component, I get:

ghcide.exe: CradleError (ExitFailure 1) ["Failed to parse result of calling stack","'stty' is not recognized as an internal or external command,","operable program or batch 
file.","\ESC[0mghcide> initial-build-steps (lib + exe)\ESC[0m","\ESC[0mConfiguring GHCi with the following packages: ghcide\ESC[0m","\ESC[0mReceived ExitFailure 1 when running","Raw command: \"C:\\\\Users\\\\ndmit_000\\\\AppData\\\\Local\\\\hie-bios\\\\wrapper-0.3.0.exe\" --version","Standard error:","","wrapper-0.3.0.exe: getEnv: invalid argument (The operation completed successfully.)","\ESC[0m"]

My guess is that's because one of the environment variables HIE_BIOS_* is not being set. I have no idea how they are meant to be set.

[mpickering]

@jneira Can you try to reproduce this please?

[ndmitchell]

Reproduction for me was the ghcide repo, changing hie.yaml to cradle: {stack: {component: "ghcide:lib"}}

[mpickering]

I tested on linux and it works correctly. The variables are set in readProcessWithOutputFile.

[jneira]

I've installed hie-bios with ec13a98 and i had to use the wrapper cause using hie-bios check give me another error:

PS D:\dev\ws\haskell\stack-test> hie-bios check .\src\MyLib.hs
hie-bios.exe: Cannot decode byte '\xbd': Data.Text.Internal.Encoding.streamDecodeUtf8With: Invalid UTF-8 stream

[jneira]

I've tested the commit before #97 and it works:

PS D:\dev\ws\haskell\stack-test> D:\bin\hie-bios\0a5cdc\hie-bios.exe check .\src\MyLib.hs
[1 of 1] Compiling Main             ( C:\TEMP\wrapper-0.3.0.hs, C:\TEMP\wrapper-0.3.0.o )
Linking C:\Users\atrey\AppData\Local\hie-bios\wrapper-0.3.0.exe ...
src\MyLib.hs:4:12:• Variable not in scope: putStrLnX :: [Char] -> IO ()
• Perhaps you meant ‘putStrLn’ (imported from Prelude)

[mpickering]

Anyone know why environmental variables don't work on windows?

[mpickering]

Is stack modifying the environment somehow to unset these variables?

[fendor]

I dont think so, otherwise the $HIE_BIOS_OUTPUT env variable wouldnt have been read either.

[mpickering]

Perhaps there is no difference on windows between setting a variable and setting it to "".

[mpickering]

Can we use lookupEnv rather than getEnv to gracefully handle this case?

[fendor]

yeah, that could be.
Of course.

[fendor]

This issue ought to be fixed by #112