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

Fix shell detection on Windows when opam is called via Cygwin's /usr/bin/env even though cmd/powershell is used #5797

Merged
merged 2 commits into from
Feb 12, 2024

Conversation

kit-ty-kate
Copy link
Member

Fixes #5644

This line was added in #4816 but looking at the relevant discussion (#4816 (comment)) I’m not sure if the change makes much sense to me (but I’m not a Windows user so most of the discussions around Windows doesn’t make sense to me anyway :D )

Copy link
Member

@dra27 dra27 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line was there for Diskuv (I don't know why Diskuv invokes opam using MSYS2's env, rather than via Unix.create_process_env et al, but I expect there's a reason @jonahbeckford?)

The idea behind the original line was that if we see "env" in the process chain, opam assumes that its in Unix-land, and guesses sh. That said, it turns out the only situation where this really matters is when env is used from a non-login terminal. In a login shell, Cygwin exports SHELL by default, so with no special handling for env (i.e. your change here), it still correctly identifies the shell. So with this PR, the time that it would be "wrong" is these steps:

  • From Powershell, or Cmd, run MSYS2/Cygwin's bash without --login (e.g. C:\cygwin64\bin\bash)
  • echo $SHELL should give /bin/bash, but cmd /c echo %SHELL% should give %SHELL% (from a login shell, you'd get /bin/bash for both)
  • opam env should give sh-output
  • /usr/bin/env opam env will now give cmd-style output
  • export SHELL
  • /usr/bin/env opam env will now give sh-style output

Given that this line has caused the wrong shell for actual users (and while using the system for which the line was originally there anyway) coupled with what I think is a fairly contrived failure mode, I think we should delete the line 🙂

@jonahbeckford
Copy link
Contributor

This line was there for Diskuv (I don't know why Diskuv invokes opam using MSYS2's env, rather than via Unix.create_process_env et al, but I expect there's a reason @jonahbeckford?)

I think because opam --help does not work on native Windows (no PAGER environment variable if I remember correctly; there may be more). I hate that hack, but --help was kinda important. And I also think that hack predated the dbuenzli/cmdliner#166 hang issue.

@kit-ty-kate
Copy link
Member Author

kit-ty-kate commented Jan 31, 2024

I think because opam --help does not work on native Windows (no PAGER environment variable if I remember correctly; there may be more). I hate that hack, but --help was kinda important. And I also think that hack predated the dbuenzli/cmdliner#166 hang issue.

Does this mean upgrading to cmdliner 1.2.0 together with this PR in the current state would fix both issues?

If so I'll upgrade the lower-bounds and vendor of cmdliner in this PR.

@jonahbeckford
Copy link
Contributor

jonahbeckford commented Jan 31, 2024 via email

@kit-ty-kate
Copy link
Member Author

There were at least two separate problems and only one has been fixed. (That linked issue expects "less" and "groff" to be in the PATH, which it is not in native Windows. That might be a third and fourth problem.)

cc @dbuenzli

@dbuenzli
Copy link
Contributor

dbuenzli commented Feb 1, 2024

I don't think it does. If it can't find a pager it outputs a plain text version (which does not need groff).

@kit-ty-kate kit-ty-kate marked this pull request as ready for review February 5, 2024 20:03
@kit-ty-kate
Copy link
Member Author

I've updated the vendored cmdliner but in any case, with or without, I was unable to reproduce your issue @jonahbeckford. --help works just fine for me in both cmd and powershell

@jonahbeckford
Copy link
Contributor

jonahbeckford commented Feb 5, 2024 via email

@kit-ty-kate
Copy link
Member Author

kit-ty-kate commented Feb 5, 2024

It works with a pager? How did a pager get into your path? (Normal users should not have the “/usr/bin/less” pager in their PATH, nor “groff”, and it would be scrolling 10 pages of help plaintext all at once.)

It does not. As far as I can see cmdliner does not support PAGER to be a path on Windows as it uses where which doesn't seem to support full-paths (whereas command -v does)

But I don't think it's too much of a problem in the short term. In the medium term however, is there a bug report somewhere on cmdliner for this?

@jonahbeckford
Copy link
Contributor

jonahbeckford commented Feb 5, 2024 via email

@kit-ty-kate
Copy link
Member Author

Then I opened one here: dbuenzli/cmdliner#185

@rjbou
Copy link
Collaborator

rjbou commented Feb 7, 2024

Shouldn't we update dependencies to cmdliner >= 1.2.0 ?

@kit-ty-kate
Copy link
Member Author

Shouldn't we update dependencies to cmdliner >= 1.2.0 ?

I don't personally think it's necessary

Copy link
Collaborator

@rjbou rjbou left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks!

@kit-ty-kate kit-ty-kate merged commit 2122af0 into ocaml:master Feb 12, 2024
29 checks passed
@kit-ty-kate kit-ty-kate deleted the fix-win-terminal-detect branch February 12, 2024 16:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[windows] opam hints to use eval after install
5 participants