Git-bash now runs in MSys2 causing issues with the `nano` binary being installed.

[jduckles]

Some users are having issues with nano not running, it is present and in the path. This could cause issues with using nano in any upcoming workshops.

They're getting a "Redirection not supported" error when trying to run nano

This new version hit last-night and our workshop attendees who installed git-bash today are seeing the problem. See the release notes on Git for Windows 2.5.0.

I think this may be a 32-bit, 64-bit problem with the version of nano.exe we're using.

[jduckles]

@ethanwhite tagging you just to make sure you see this.

[ethanwhite]

Thanks for reporting @jduckles. Unfortunately I'm a bit buried with the start of the semester at the moment, so I probably won't have a chance to take a look at this for a while.

Sorry for not being able to jump on this right away. PRs or more info in the comments of this issue are certainly welcome if you have the chance to run it down.

[jduckles]

I don't have a Windows machine to even take a stab at this. Do you know of someone that is a Windows instructor I might ping? A stop-gap solution might be to make the download link go to a 2.4.x version of git-bash. Only problem I see is that all currently planned workshops will have to pull down the change from the template to fix that link.

[jiffyclub]

From Dirk Eddelbuettel:

We told participants in today's workshop to say 'notepad' when 'nano' fails. A better solution would certainly we welcomed by many.

[ethanwhite]

The change in behavior resulted from the switch in Git for Windows to using MinTTY instead of the standard Windows console. Work arounds that can be used immediately:

1. Have the students reinstall Git for Windows to use the Windows console. It's one of the option pages during the Git for Windows install.
2. Run winpty nano in place of nano.

I'm working on figuring out how to make this all seamless again, but wanted to get the quick fixes out for those of you having issues right now.

[lo5an]

I'm poking around with this tonight and the ConEmu program suggested in the Git for Windows FAQ seems to work fairly well. It's less wonky than winpty for me and, there's a configuration menu option to start up with bash by default.

[ethanwhite]

I'm poking around with this tonight and the (ConEmu)[https://conemu.github.io/] program suggested in the Git for Windows FAQ seems to work fairly well. It's less wonky than winpty for me and, there's a configuration menu option to start up with bash by default.

If I'm understanding this correctly this would require installing an additional program and changing a configuration option from the default. Is that correct? If so, then I'm not sure I understand the benefit of this over instructing the students to change the appropriate installation option in the standard Git for Windows install to avoid using MinTTY.

[ethanwhite]

Just caught a typo in my earlier work around it's winpty nano. Sorry about that.

[lo5an]

That is probably the correct short-term solution. It gets things back to exactly where they were before the new Git release.

I always feel bad for people stuck using the default Windows console, though. It has gotten a tiny bit better in Windows 7 and 8, but it still seems distractingly hard to use. Both ConEmu and MinTTY are nicer.

[ethanwhite]

Ah, got it. Yes, there are definitely better working environments, but when we've discussed this in the past the increased probability of errors in installation (e.g., by adding another program to the stack) have been considered to outweigh the benefits for the purposes of workshops.

[lo5an]

Not strictly relevant to this issue, but I've been tinkering around tonight and the MSYS2 stuff looks pretty promising. It also uses MinTTY, but it seems to wire up nano correctly when you install it, and I don't see a winpty process running.

[ethanwhite]

I can see two solutions to this general problem at the moment:

1. Change the installation instructions to ask the students to install Git for Windows with the Windows console option. They would need to make a change on the 5th page of the installer wizard. We know from experience that requiring students to change the defaults will increase the number of issues because some of them won't remember to make the change.
2. In the installer we alias all the necessary programs (this affects at least nano and python and probably R) to run through winpty, e.g., winpty nano. This general approach has been reported to work well, but can have minor side effects [1]. I haven't been able to figure out how to detect whether the terminal emulator is MinTTY so that we could only alias through winpty when necessary. The biggest risk here is the unknown in that once this is run on a few hundred systems we may find some cases where it doesn't work well and needs more patching (e.g., maybe there are issues with older Git Bash installs).

If folks have opinions on the preferable approach I'd love to hear them. Pinging @wking & @gvwilson.

[1] https://code.google.com/p/mintty/issues/detail?id=56

[lo5an]

Maybe something along the lines of nano || winpty nano would be OK?

[ethanwhite]

Maybe something along the lines of nano || winpty nano would be OK?

Good thought! This works for both nano and R, it doesn't work for launching Python since python runs, it just doesn't run interactively so it just hangs waiting for input. This is still a nice middle ground for the most important cases and I'll add this nice tweak to the fix I'm testing now. Thanks @lo5an!

[lo5an]

I do also notice that TERM seems to get set differently between the MinTTY and the default windows console:

For MinTTY:

lmc@WIN-2E1N3DP86I0 MINGW64 ~
$ echo $TERM
xterm

For cmd.exe:

lmc@WIN-2E1N3DP86I0 MINGW64 /
$ echo $TERM
cygwin

[rmcd1024]

This seems to be a fix (we're in the middle of a class so it's not fully field-tested yet).

From the user's home directory in git-bash, type

echo "winpty nano" >  .swc/lib/nano/nanofix
chmod +x .swc/lib/nano/nanofix

Now specify nanofix as the editor.

[gvwilson]

Thank you all for tracking this one down so quickly. Also, why is software so fricking hard??

[rmcd1024]

It's not quite right as nano needs a command line argument for the file to edit:

echo "winpty nano $1" >  .swc/lib/nano/nanofix
chmod +x .swc/lib/nano/nanofix

Now you can pass "nanofix -w" as the editor invocation. Hopefully this works!

[rmcd1024]

Sorry, this is not working correctly. The cursor keys don't work properly when nanofix is launched (you can edit the start of the file). Suggestions welcome... Perhaps for windows users we should just recommend notepad?

[ethanwhite]

@rmcd1024 - if you're looking for an easy fix for folks in a workshop right now, the most robust one is my first suggestion above to reinstall Git for Windows and on the 5th screen on the installer select Windows console instead of MinTTY.

[ethanwhite]

Sorry, this is not working correctly. The cursor keys don't work properly when nanofix is launched (you can edit the start of the file).

Wow, this is an import catch that I wish I'd made last night. Thanks for reporting back @rmcd1024! I think our only choice at this point is to change the set up instructions or hard link to an older version of git bash.

[cgates]

FYI while it is a clearly suboptimal, short-term workaround, you can type "start" from gitbash which will launch a win console in the current working dir with a reasonable PATH env variable. From this new console you can launch python, sqllite, nano and they behave as expected.

[ethanwhite]

PRs are now in to both the workshop-template [1] and site [2] repos to change the installation instructions. Once these are in instructors of workshops who have already setup their websites should pull these downstream or just copy and paste the changes into their sites.

Since this seems to be the best we can do short of a larger scale reconsideration of the Windows stack I'm going to go ahead and close this issue. If anyone comes up with a better/supplemental plan for helping improve this situation with our Windows installer please open a new issue since this one has gotten a little messy.

Huge thanks to @jduckles and folks on the mail list for reporting and to @lo5an, @rmcd1024, and @cgates for the great fixes/debugging/suggestions.

[1] https://github.com/swcarpentry/workshop-template/pull/235 [2] https://github.com/swcarpentry/site/pull/1059

[wking]

On Fri, Aug 21, 2015 at 05:25:57PM -0700, Ethan White wrote:

The change in behavior resulted from the switch in Git for Windows to using MinTTY instead of the standard Windows console.

It looks like msysGit has been superseded by Git for Windows 2.x 1. There are MSYS2 packages for Git 2, nano 3, and nano's syntax highlighting 4, which we can install using the MSYS2 version of pacman 5. I expect that converting our installer to use MSYS2-native applications installed by a real package manager will be the long-term solution here.

[ethanwhite]

I expect that converting our installer to use MSYS2-native applications installed by a real package manager will be the long-term solution here.

I agree that this looks promising and it would be great if someone has the time to play around with this and report back.

[wking]

Also, the Git for Windows SDK 1 seems to be using Inno Setup 2. We've previously resisted using the full SDK (previously msysGit vs Git for Windows) because of the installed size 3. If that's still a concern, maybe we can adapt the build-extra approach to setup our own SWC-installer. We get to use a pacman-based system to manage dependencies, and learners get a one-click installer.

[hoytpr]

A closed thread...this is how I learn. In my situation there were other applications that interfered with the SWC git/bash installation (probably the Win-python IDLE editor). A clunky way to get the NotePad++ editor (my fave) to at least run from the GitBash window is to add a batchfile into the GitBash directory. For example a file named "npp.bat" has these contents:

::start 
cd C:\Users\<username>  
"C:\Program Files (x86)\Notepad++\notepad++.exe" %1 
::end

save this file, and execute it from within the GitBash window using:

./npp.bat <filename>

This doesn't open Notepad++ inside the GitBash window, but it opens it quickly, and gives the "feeling" you are working with the command-line window at all times. It's similar to what cgates suggested using "start". Note that you may have to change the paths in the batchfile to the individual computer.

[Murmur]

Old topic but encountered same 'redirection is not supported' problem in Nano(2.5.3) windows release. Cursor keys did not work, Git config property core.editor did not work as expected. This is how I solved using nano as an internal editor for rebase and etc git commands.

Download Windows binary and unzip. https://www.nano-editor.org/dist/v2.5/NT/. I use c:\apps\commandsUnix\ folder. Create the following nano script to your ~/bin/ home folder. Set script file to core.editor configuration property value. Try editing text files git console prompt should wait for nano process to end.

#!/bin/sh
## Save this script to 'GitPortable/Data/home/bin/nano' file.
## winpty wrapper fixes MSys2 'redirection not supported' problem(not working anymore),
## instead use start wrapper.
## run git config --global core.editor "/C/apps/GitPortable/Data/home/bin/nano"
START //WAIT /C/apps/commandsUnix/nano.exe "$@"

[shoogle]

@ethanwhite said:

I haven't been able to figure out how to detect whether the terminal emulator is MinTTY so that we could only alias through winpty when necessary.

Solution:

Put the following in ~/.bash_profile:

function _print_terminal_emulator() {
  local parent_ps="$(ps -p $PPID)"
  echo "${parent_ps##*/}"
}

if [[ "$(_print_terminal_emulator)" == "mintty" ]]; then
  function nano() { winpty nano "$@" ;} && export -f nano
  function python() { winpty python "$@" ;} && export -f python
  # more functions...
fi

Of course, you could use aliases instead of functions, like this:

if [[ "$(_print_terminal_emulator)" == "mintty" ]]; then
  alias nano="winpty nano"
  alias python="winpty python"
  # more aliases...
fi

But take note that the Bash manual states:

For almost every purpose, shell functions are preferred over aliases.

If you want to be able to use nano as the editor for git (e.g. with EDITOR=nano git commit --amend) then you must define nano() as a function (and export it too!). If you tried EDITOR=nano git commit --amend it would fail with the error Could not execute editor if nano is an alias rather than an exported function.