Open jneira opened 4 years ago
Thanks for the report.
Unfortunately I'm not actively supporting these tools (as they work well enough for me). Especially, I won't investigate why something doesn't work. Windows is quite a mystery for me.
For that reason I'm not actively advertising their existence either.
Can not reproduce on win 10:
> cabal-store-check --with-compiler ghc --repair
[ 0.00045] debug: runProcess cwd=C:\Users\Privat\AppData\Roaming\ghc ghc --info
[ 0.05799] info: Reading global package db
[ 0.08145] info: 32 packages in C:\ProgramData\chocolatey\lib\ghc\tools\ghc-8.6.5\lib\package.conf.d
[ 0.08162] info: Reading store package db
[ 0.32378] info: 314 packages in C:\Users\Privat\AppData\Roaming\cabal\store\ghc-8.6.5\package.db
[ 0.71628] info: 0 directly broken library components
[ 0.71635] info: 0 transitively broken libraries
[ 0.71636] info: 0 broken executable components
[ 0.71637] debug: runPeu completed successfully
Only happens when this cabal-helper bug occurs?
@fendor it works for ghc
(see my first report) but no for ghc-${version}
Thanks, misread the issue! Can reproduce!
I think this is either a problem with file extensions in process
itself or not even a bug at all but expected behaviour on windows.
The following snippet, already errors:
let p = proc "ghc-8.6.5" ["--info"]
readCreateProcess p ""
But this succeeds:
let p = proc "ghc-8.6.5.exe" ["--info"]
readCreateProcess p ""
Also, the following calls succeeds:
cabal-store-check -w ghc-8.6.5.exe
@jneira Maybe this is expected behaviour on windows? IIRC, the extension is important to windows.
well cabal -w ghc-8.4.4
works for windows and the fix would be "simply" add .exe
if it is not already as suffix.
Note that -w D:\bin\ghc-8.4.4\bin\ghc-8.4.4
also works and it has not the extension, so there would be anoher factor involved.
We can easily introduce a work-around for it. I just think the behaviour is weird for process
.
As stated in https://github.com/phadej/cabal-extras/pull/20#issuecomment-584068495, it seems the solution should be upstream (in the directory package). I will keep the branch with the windows hack in the meanwhile, just in case someone wants to use it.
After a little more thinking, I'd like to have shell like search available in the library. I.e.
On unix-like systems simulate:
% command -v ghc-8.6.5
/opt/ghc/bin/ghc-8.6.5
and on windows whatever PowerShell does in:
Get-Command ghc-8.6.5
(It might find .bat
and .cmd
stuff, but I think that's what you should support as well, I think https://github.com/PowerShell/PowerShell/blob/a34d0f3e808659b0c07b8fdac83aaae1dae43c21/src/System.Management.Automation/engine/CommandSearcher.cs is one source of insight what happens in PowerShell, but I'm not 100% sure, I cannot read C#).
Obviously not listing anything for aliases and functions (which both AFAIK handle). The use-case is to simulate how the shell finds the commands, as that what you kind of expect when you say cabal-store-check -w ghc-8.6.5
.
I think that's reasonable feature to have in directory
, one could even argue that is exactly what findExecutable
should do (and not some other function).
Hi, first of all thanks for these useful tools. Trying to fix the cabal-helper build for ghc-8.4.4 (my default one is ghc-8.6.5) i've go this error:
I guess it should be relatd with windows
The full path works: