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

Stack exec does not properly pass arguments to command on windows #813

Closed
themoritz opened this Issue Aug 18, 2015 · 18 comments

Comments

Projects
None yet
7 participants
@themoritz

themoritz commented Aug 18, 2015

On windows, stack does not pass all the arguments that come after the double dash -- to the command. The following works:

stack exec cabal -- install

But the following does not (it shows stack's version):

stack exec cabal -- --version

This shows stack's usage (i.e. stack thinks the --global option is intended for stack):

stack exec cabal -- install --global

All the above commands work as expected on linux.

@chrisdone

This comment has been minimized.

Member

chrisdone commented Aug 18, 2015

Huh. Is this an optparse-applicative thing?

@borsboom

This comment has been minimized.

Contributor

borsboom commented Aug 23, 2015

It seems to work for me:

C:\Users\emanu>stack exec cabal -- --version
Run from outside a project, using implicit global config
Using resolver: lts-3.0 from global config file: C:\Users\emanu\AppData\Roaming\stack\global\stack.yaml
cabal-install version 1.22.6.0
using version 1.22.4.0 of the Cabal library

I tried this on Windows 10, using stack build from master.

@themoritz, can you try it with the latest master, and can you provide more details about your environment if it still fails?

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Sep 6, 2015

I've confirmed that this works as expected on Windows as well, closing due to lack of repro.

@snoyberg snoyberg closed this Sep 6, 2015

@borsboom borsboom modified the milestone: Options parsing Sep 12, 2015

@themoritz

This comment has been minimized.

themoritz commented Sep 28, 2015

I can confirm that this is no longer an issue in newer stack versions (just tested with 0.1.5.0 on Windows 10). Sorry for the repro delay.

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Sep 28, 2015

No problem thanks for the confirmation

@snoyberg snoyberg reopened this Sep 28, 2015

@snoyberg snoyberg closed this Sep 28, 2015

@jgm

This comment has been minimized.

jgm commented Nov 15, 2015

I'm getting the issue reported above, with stack 0.1.6.0, 32-bit Windows, downloaded from the releases page. This is on Windows 7.

stack exec cabal -- --version

returns the version of stack, not cabal. I can't use stack exec on this machine because of this problem.
Edit: I've tried stack upgrade and it just confirms I have the latest version.
Edit2: stack exec cabal -- update works fine.

@jgm

This comment has been minimized.

jgm commented Nov 15, 2015

I found a strange workaround. This works:

stack exec cabal -- -- --version
@borsboom

This comment has been minimized.

Contributor

borsboom commented Nov 18, 2015

@jgm: I haven't been able to reproduce this on Windows, using stack-0.1.6.0 from the releases page (or stack built from master). There have been some changes to command-line argument parsing since 0.1.6.0 was released; perhaps try building the latest stack from master?

@bdoering

This comment has been minimized.

bdoering commented Nov 24, 2015

@jgm, I am having the same experience. Using -- -- as a delimiter works, using only -- does result in a usage message. I am using stack version 0.1.8.0 x86_64 on Windows 7, installed with stack upgrade (but identical behavior was visible with the earlier stack 0.1.4).

@jgm

This comment has been minimized.

jgm commented Nov 24, 2015

I was on Windows 7 too; I wonder if this is Windows-version
dependent?

+++ Björn Döring [Nov 24 15 13:51 ]:

[1]@jgm, I am having the same experience. Using -- -- as a delimiter
works, using only -- does result in a usage message. I am using stack
version 0.1.8.0 x86_64 on Windows 7, installed with stack upgrade (but
identical behavior was visible with the earlier stack 0.1.4).


Reply to this email directly or [2]view it on GitHub.

References

  1. https://github.com/jgm
  2. #813 (comment)
@mgsloan

This comment has been minimized.

Collaborator

mgsloan commented Nov 24, 2015

Seems like this is worthy of re-opening, if it reliably repros on windows 7 (though, I haven't tried it). I wonder what it is about windows 7 argument parsing that does this? Is there something that can be done about it?

I'm almost inclined to say "Lets document the limitation somewhere, and encourage use of bash or powershell instead".

@jgm

This comment has been minimized.

jgm commented Nov 25, 2015

I was using powershell in Windows 7.

+++ Michael Sloan [Nov 24 15 15:47 ]:

Seems like this is worthy of re-opening, if it reliably repros on
windows 7 (though, I haven't tried it). I wonder what it is about
windows 7 argument parsing that does this? Is there something that can
be done about it?

I'm almost inclined to say "Lets document the limitation somewhere, and
encourage use of bash or powershell instead".


Reply to this email directly or [1]view it on GitHub.

References

  1. #813 (comment)
@bdoering

This comment has been minimized.

bdoering commented Nov 25, 2015

Me too. I just checked and it works as expected with the standard cmd shell, but powershell requires the double -- --.

@mgsloan

This comment has been minimized.

Collaborator

mgsloan commented Nov 25, 2015

Ahah! So really it's a powershell thing, interesting!

@themoritz

This comment has been minimized.

themoritz commented Nov 25, 2015

I can confirm all of the above. When I originally posted this issue I was using powershell on Win 7, too.

@borsboom borsboom changed the title from Stack exec does not properly pass arguments to command on windows to Stack exec does not properly pass arguments to command when using Windows PowerShell Nov 25, 2015

@borsboom borsboom changed the title from Stack exec does not properly pass arguments to command when using Windows PowerShell to Stack exec does not properly pass arguments to command on windows Nov 25, 2015

@borsboom

This comment has been minimized.

Contributor

borsboom commented Nov 25, 2015

I just tried PowerShell on Windows 10, and it didn't seem to exhibit this problem. I don't know anything about PowerShell, but this stackoverflow Q/A looks possibly relevant; it seems PowerShell interprets -- itself for function calls, and maybe the Windows 7 version has a bug where it also does that when calling an external command. Have any of you tried quoting the --? e.g.:

stack exec cabal "--" --version

If it's a PowerShell issue where it's not actually passing the first -- to stack, I think we'll just have to accept that, especially if it's fixed in Windows 10 (it's not so unlike having to remember to escape or quote arguments containing * or other characters the shell interprets when using bash). An FAQ entry is probably in order, though.

@jgm

This comment has been minimized.

jgm commented Nov 25, 2015

I just did, and I can confirm that quoting the "--" makes it
work properly. I also tried writing a small program that
just prints the outputs of System.Environment.getArgs, and
that reveals that the -- is not being passed through as an
argument.

So, I think your diagnosis is correct, and a FAQ entry
suffices to fix this.

+++ Emanuel Borsboom [Nov 25 15 04:13 ]:

I just tried PowerShell on Windows 10, and it didn't seem to exhibit
this problem. I don't know anything about PowerShell, but [1]this
stackoverflow Q/A looks possibly relevant; it seems PowerShell
interprets -- itself for function calls, and maybe the Windows 7
version has a bug where it also does that when calling an external
command. Have any of you tried quoting the --, e.g.:
stack exec cabal "--" --version

borsboom added a commit that referenced this issue Nov 26, 2015

borsboom added a commit that referenced this issue Nov 26, 2015

@borsboom

This comment has been minimized.

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