Closed jduckles closed 9 years ago
@ethanwhite tagging you just to make sure you see this.
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.
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.
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.
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:
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.
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.
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.
Just caught a typo in my earlier work around it's winpty nano
. Sorry about that.
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.
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.
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.
I can see two solutions to this general problem at the moment:
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.
Maybe something along the lines of nano || winpty nano
would be OK?
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!
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
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.
Thank you all for tracking this one down so quickly. Also, why is software so fricking hard??
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!
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?
@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.
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.
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.
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
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.
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.
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.
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.
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 "$@"
@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.
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.
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.