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

Cargo can't determine the terminal width on MSYS terminals #5124

Closed
alexcrichton opened this issue Mar 5, 2018 · 8 comments · Fixed by #6010
Closed

Cargo can't determine the terminal width on MSYS terminals #5124

alexcrichton opened this issue Mar 5, 2018 · 8 comments · Fixed by #6010
Labels
O-windows OS: Windows

Comments

@alexcrichton
Copy link
Member

I'm not really sure what the API is to do this, but because Cargo can't determine the width here it doesn't print out fancy progress bars which is sad!

@alexcrichton
Copy link
Member Author

cc @BurntSushi, you wouldn't know how to do this would you?

@BurntSushi
Copy link
Member

Sadly, no idea. The tty hack is about as far as my knowledge of MSYS goes. :-(

@alexcrichton
Copy link
Member Author

Ah well, worth a shot! I made an attempt here but it turns out although COLUMNS is an env var in the shell it's not an env var in the Rust process (for whatever Reason)

@ehuss
Copy link
Contributor

ehuss commented Mar 7, 2018

I took a little look at this. Due to the way Cygwin/msys handles the console, it can be quite difficult to get the correct information. Opening "CONOUT$" with CreateFileA gets close, but only really works with Cygwin's conhost or ConEmu, but doesn't work with mintty (it always returns 80 columns). Internally Cygwin uses shared NT objects to communicate TTY information, so we can't easily access that without linking to cygwin's libc. If you want to tweak your attempt, instead of using GetStdHandle, you can do something like this:

let h = winapi::um::fileapi::CreateFileA("CONOUT$\0".as_ptr() as *const CHAR,
    GENERIC_READ | GENERIC_WRITE,
    FILE_SHARE_READ | FILE_SHARE_WRITE,
    ptr::null_mut(),
    OPEN_EXISTING,
    0,
    ptr::null_mut()
);

And then you can use that handle with GetConsoleScreenBufferInfo when you know it is an msys pty.

One workaround would be to use ANSI escape sequences to communicate with the terminal (something like "\x1b7\x1b[r\x1b[999;999H\x1b[6n\x1b8"). However, that seems kinda gross to me and doesn't work very well. Ugh.

@alexcrichton
Copy link
Member Author

Ah thanks for looking into this @ehuss! It may be the case that we could just detect a tty and assume 80 columns as well

@ehuss
Copy link
Contributor

ehuss commented Mar 7, 2018

we could just detect a tty and assume 80 columns as well

That sounds reasonable to me!

@kip-13
Copy link

kip-13 commented Sep 11, 2018

This solution exists in nightly dist ?

@ehuss
Copy link
Contributor

ehuss commented Sep 11, 2018

This solution exists in nightly dist ?

Unfortunately, no. I can take another look at a solution.

ehuss added a commit to ehuss/cargo that referenced this issue Sep 12, 2018
This is an alternate approach to determining the window size that works on more Windows terminals.

Terminals with accurate width detection: Normal Windows console, cmder, ConEmu, VS Code, Hyper, etc.

mintty-based terminals will always be 60 characters wide. Cygwin in a command console is ok, but
running under x-windows will also always be 60.

Tested on Windows 8 and Windows 10.

Closes rust-lang#5124.
bors added a commit that referenced this issue Sep 12, 2018
Get window size on more Windows terminals.

This is an alternate approach to determining the window size that works on more Windows terminals.

Terminals with accurate width detection: Normal Windows console, cmder, ConEmu, VS Code, Hyper, etc.

mintty-based terminals will always be 60 characters wide. Cygwin in a command console is ok, but
running under x-windows will also always be 60.

Tested on Windows 8 and Windows 10.

Closes #5124.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
O-windows OS: Windows
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants