Getting Julia REPL working in Windows git/bash

I know one of the common Julia workflows in Windows is to run Julia through MinGW’s bash (popularly available with git):

I’m working on a Windows distribution of Julia and was wondering if wrapping julia processes through MinGW should be one of the options, or maybe even the default option considering how posix focused the community is.

But after my first few tests on running this pipeline, I found that the julia REPL gets jammed after calling run(ls)

The same happens from powershell and when running in mintty directly. Can anyone confirm the same on their system?

I don’t know what’s going wrong here, but if I run the vanilla julia distribution from bash on windows, it works fine. But if I run julia with winpty, it starts printing similar control characters that you’re seeing.
That is git bash:

$ julia
julia> run(`ls`)
Process(`ls`, ProcessExited(0))

works fine. But

$ winpty julia
julia> run(`ls`)
?[0mProcess(...[some more stuff here]
[some more control characters]julia> [more control characters]

breaks. Could be a clue for you to troubleshoot further.

Okay that is interesting, my git bash doesn’t even work. What version of git are you on exactly? Mine is:

$ where git
C:\Program Files\Git\cmd\git.exe

$ git --version
git version

What I actually do is run the MINGW64 terminal

Why do you need to run powershell or cmd and start bash from there?

I think you might have seen this, but in case you haven’t: Portable Julia

1 Like

I get the same jumbled text even when in Mintty (MINGW64), so that doesn’t change anything:

Thanks for the link to your portable julia packaging, will check it out.

Also in shell mode:

I’m gonna install an updated version of git and see if that fixes anything.

Newer version of Git didn’t help, but it seems like the problem occurs in Julia version 1.5.3. I quickly downloaded an arbitrarily old version of Julia and saw that it doesn’t occur in Julia version 1.1.1
On which version of Julia did you guys test this on?

Edit: ran some extra tests

  • works on 1.1.1
  • works on 1.3.1
  • works on 1.4.2
  • doesn’t work on 1.5.3 (also tested on an additional newly downloaded version)
  • works on 1.6.0-DEV.1564 (2020-11-24)

So whatever it is, it does seem to get fixed somewhere in 1.6

Some further investigation lead me to believe that this doesn’t have anything to do with the shell environment, but with the actual mingw binaries being executed.

For example, if I run a normal Julia session in Windows, then (correctly so) echo doesn’t work, but does work under cmd /c "echo ...". But if I run the echo.exe binary from MinGW directly, then it also leaves my REPL in an unusable state. So in this case its the actual output of the echo.exe binary that does this, not because of any runtime environment shenanigans.

That is weird. I don’t see anything wrong:

PKrysl@Spectre MINGW64 ~
$ echo "${BASH_VERSION}"

Edit: Your example.

Edit 2: with the latest portable Git.

When you say it works on all versions except 1.5.3, are you testing with the official julia distributions or your juliawin distributions? Because I only see a single release on the github page of juliawin and it is not clear which julia version that is.

I personally tested with 1.5.3.

When you tested, what were the results please?

All my tests were with official Julia releases. I found these releases here:

I didnt have to install them, I extracted them with universal extractor .

Some of the versions required two rounds of extraction, but is is quite handy in order to get a bunch of portable releases going.

It is the first reply in this thread. Everything works well except if I try to use winpty.

EDIT: the git version is

1 Like

I have the same problem. If I double click and use the default Windows console I have this problem.

However, if I use ConEmu I don’t.

Hello all:

I have now tried this with Sublime Text 4. Julia is run in Terminus, and ST is started in the git bash.
With 1.5.1 and 1.5.2, shell commands are fine; with 1.5.3 shell commands mess up the Julia prompt.
1.6 is again fine.