Fails to start in Msysgit bash on Windows

[sidfarkus]

Trying to use this on Windows 10 Pro Version 10.0.18362 Build 18362

Installing with Rust:
cargo install broot

And adding broot to bashrc:
source /c/Users/myuser/AppData/Roaming/dystroy/broot/config/launcher/bash/br

Running br gives me the following output:

Getting mode failed
Termimad Error : "Crossterm error"

When I run broot in powershell on my system it functions but is slow to redraw.

[Canop]

I asked Timon, the leader of the crossterm project.
It's a known problem:

We can't call into WinApi from cygwin terminals. I'm not sure how to solve that problem. Since we have to use it for input reading for example.

[sidfarkus]

Fooey; it does sound like it's difficult to tie those things together. I think this setup just might not be supported for a while then.

[Canop]

@sidfarkus There's still hope. I reopen the issue as the problem is clear and is absolutely not solved

(but yes this might take a while)

[carloscm]

This combination almost works:

• Windows 10 cmd.exe
• Use cygwin64
• Use ConEmu x64
• Use the broot.exe builds from github

1. Start a cmd.exe prompt inside ConEmu
2. Inside the cmd.exe prompt, invoke bash.exe from cygwin
3. Inside that bash.exe you can then launch broot.exe, with the following issues:

• It will output Win32 UNC paths instead of the cygwin.dll mapped paths (this is expected, since broot.exe is not compiled with the cygwin toolchain)
• It doesn't actually change the current folder for the bash session
• It refreshes the screen slowly
• The first line of output is always cut out

The first and second issue are what will probably make this a futile goal, since there is no native cygwin build of the Rust toolchain as far as I am aware. So even if the screen I/O issues are solved, broot.exe will use Win32 paths/APIs and cygwin shells will use the cygwin.dll equivalents, which are not compatible and/or invisible to each other.

EDIT
Tried another approach, building with MSYS2 using the mingw-w64 repo, which includes its own build of rust.

• Use MSYS, launch a mingw-w64 console
• Make sure packages are updated: pacman -Syuu
• Install rust: pacman -S mingw-w64-x86_64-rust
• cargo install broot

It all installs and builds cleanly, but this time broot.exe exits with the "crossterm error" message. Given that the cargo installed by this approach is giving me Win32 style paths, I suspect that even if made to work it would still be using Win32 paths, not the msys2 style ones bash.exe from msys2 would expect. So it has the same issue as trying to run broot inside and for cygwin usage.

EDIT2
Sorry for the spam, I just hope somebody finds this useful and/or it helps the developer when testing or when supporting their users.

I managed to get br to do proper console I/O under a cygwin bash.exe, it was a mater of making sure you are using a very recent cygwin version with support for the new Windows console API, then the right console emulator.

• Update to the latest cygwin, at least 3.1.1, to get ConPTY support (Fix crossterm MinTTY, ConPTY comitability issues on Windows crossterm-rs/crossterm#168 (comment))
• Use a terminal that supports ConPTY. The new Windows Terminal does and works fast, default cmd.exe does too. ConEmu does, but it's mangling the output, as does the mintty bundled with cygwin itself. But the mangled output is at least a step up from the previous fatal error!

This launches br and your can use the UI normally, but when trying to cd in to a folder it panics with:

thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: RecvErrorIO Error : ', "src\libcore\result.rsThe system cannot find the path specified. (os error 3):"999

This doesn't happen under PowerShell or cmd.exe. (see EDIT3)
I've tried a quick patch to the br function in the vein of (it's hardcoding C:):

    d=${d//\\\\?\\/}
    d=${d//\\/\/}
    d=${d//([A-Z]):\//\/cygdrive\/c\/}

But it seems it never actually reaches this point, since the fatal error is a Rust error.

EDIT3
I was wrong, the panic happens also under Powershell, at least for me, so it appears to be unrelated to the fact the invoking shell is cygwin bash.

EDIT4
Success! The panic was actually broot reporting it cannot find the --outcmd file, since the mktemp path uses cygwin paths (for the cygwin bash case) or the file didn't exist to begin with (for my manual testing under a Poweshell console).

Translating the mktemp path when calling broot.exe, then translating out any paths before doing the eval, makes br/broot finally usable under cygwin (provided you are using a very recent cygwin version and the right console program as per EDIT2):

function br {
    f=$(mktemp)
    ft=$(cygpath.exe -w $f)
    (
	set +e
	broot --outcmd "$ft" "$@"
	code=$?
	if [ "$code" != 0 ]; then
	    rm -f "$f"
	    exit "$code"
	fi
    )
    code=$?
    if [ "$code" != 0 ]; then
	return "$code"
    fi
    d=$(<"$f")
    rm -f "$f"
    # d is a bash expression, not a path, so we cannot use cygpath
    # remove UNC prefix
    d=${d//\\\\?\\/}
    # unix slashes
    d=${d//\\/\/}
    # translate drive identifier if present
    re='([A-Za-z]):'
    while [[ $d =~ $re ]]
    do
        drive_upper=${BASH_REMATCH[1]}
        drive_lower=${drive_upper,,}
        d=${d//$drive_upper\:\//\/cygdrive\/$drive_lower/}
    done
    eval "$d"
}

[Canop]

Don't worry for the "spam". It's better to record it. Even if I don't really have time now to study this, somebody else may, now or later.

[gadros]

1. can't use it in bash - also get the rust crossterm error. frustrating.
2. when ran in the new windows terminal or powershell can't 'cd' into any folder because alt+enter toggles the window between maximized or normal size (no easy work around).
   --> renders it unusable. if anyone has a workaround - please post.
3. the result of broot --install wrote path in windows path format in .bashrc and .bash_profile (so i manually reversed these)

[Canop]

@gadros For the alt-enter hijacked by your terminal, you can define another shortcut in conf.toml, for example

[[verbs]]
key = "ctrl-j"
execution = ":open_leave"

[gadros]

thanks a lot for the quick and prompt reply.