interactive flag

[krazyito65]

wslgit/src/main.rs

Line 83 in 4a61427

.arg("-i")

There a reason the -i flag is used here? I have an issue where I use https://github.com/magicmonty/bash-git-prompt which has problems with slowness on my wsl terminal. While I deal with it using it on my own, this severely slows down my usage of wslgit becasue it waits for that to constantly load.

If the -i flag were removed that would fix my problem, but I'm not sure if that would affect others? Whats the reason for using that flag if you're making 1 off commands anyway each time you run git?

[krazyito65]

Actually in the process of building this from source to see if it actually fixes my problem. Need to install rust first. Will update when I can.

[krazyito65]

Also while waiting for this to install i did some other testing.

As far as I'm aware, the bash.exe is deprecated in favor of wsl.exe

I tested running these commands as so:

C:\>wsl git config --get-all user.name
Leon Solis

and seemed to work very quickly Not sure if that's an option for you.

[krazyito65]

Hah, i think this PR does everything I've talked about as well.
#23

[andy-5]

Yes, exactly. The discussion that led to PR #23 is in issue #16.

The reason for the -i flag is that things like ssh-agent etc. are commonly started in .bashrc, but only for interactive shells (because the standard .bashrc exits early if -i is not present).

As you noticed, startup can be slow if .bashrc does many things in interactive mode. Therefore, PR #23 runs a non-interactive shell if the user manually overrides the startup file with the environment variable BASH_ENV (because then we assume the user wants this behaviour and knows what he's doing). However, this currently only works for Windows 10 insider builds 17063 and later, as the environment variable must be passed from Windows to WSL.

If you have access to a Windows insider build and have Rust installed, it would be great if you could test PR #23 to see if it works for you. Any feedback is welcome.

I'm closing this issue because the use case is already discussed elsewhere. However, feel free to provide further feedback here or on #23.

[krazyito65]

Ahhh.. I didn't realize the ENV variable were part of an 'unreleased' build. I thought it came when they added wsl.exe (I guess that explains my small failures when i did try to look for it).

I'll keep an eye out when the new build comes out and ill try the PR before/after its merged in.

[krazyito65]

I think reading through everything again, it seems I could set those variables myself and test the PR?

It's late night for me, so can try in the morning when I get a chance, but just wondering if that's true.

[andy-5]

You always need to set these variables yourself for the PR, it only changes the behavior of wslgit if the variables were set by the user.

The code to respect these variables is currently only available in the PR, so you need to build it yourself.

For the variables to have an effect, they must be set before bash starts, so they must already be set by WSL before executing bash. This feature of forwarding arbitrary environment variables to WSL is currently only available in Windows Insider builds.

[krazyito65]

Thanks for clearing that up. As I said I'll wait for the insiders build to get released and try it then. For now, the code looks simple enough I was able to recompile without the -i flag. Thanks for the help.