Editing through ssh session is broken

[graphixillusion]

I already got this issue with the previous version (4.6) that's why i asked in the other thread for new build but the issue i'm going to describe still persist: editing with nano through ssh session is completely broken. I mean, arrow keys doesn't work, enter key doesn't work, space doesn't work; Ctrl+x seems to work but strange chars will be printed out upon exit in the shell ([?2004h[?2004l). No problem with editing with local files in the Windows cmd shell. I forgot to mention that i've tried with putty and the official windows ssh client: same results in both scenarios.

[lhmouse]

Please try MSYS2's nano. Keyboard inputs are handled by the native (i.e. not basing on any form of POSIX simulation) ncurses which does not conform to POSIX.

[graphixillusion]

Just tried to start the ssh session whithin MSYS2 environment and i've got the same results as above. This issue seems to be linked to the target machine's nano (which runs Windows with nano too): the ssh session brokes something somehow during it becouse with local files everything works good. Can you reproduce the problem?

[lhmouse]

nano-win is not meant to be functional over SSH (note this is ncurses' limitation not nano's). You should use MSYS2's nano which can be installed via pacman -S nano and located at /usr/bin/nano.

[garoto]

@graphixillusion you might be interested in this: https://github.com/billziss-gh/sshfs-win/

Mount your ssh session as a networked drive and then use your local nano copy to edit files on the remote machine.

[graphixillusion]

Thank you to everyone for the support. I think i've found another workaround: use the MSYS2 nano as @lhmouse suggested, then create a shim to nano.exe and put the created shim files inside a dir which is in an environment variable, so when i ssh remote that machine and type "nano whatever" it works using the MSYS2's nano. Now there is only one problem left: type the special characters of my keyboard, like àèìòù and so on (IT keyboard).

[lhmouse]

The reason why it doesn't over SSH is a bit complex but I'll try to elaborate a little:

A POSIX terminal (such as the ones you get on a Linux machine by pressing F1 to F6 which are virtual terminals, or the ones created by SSH sessions or GNU screen which are pseudo terminals) is basically a bidirectional character stream. You can move the cursor around, scroll an area, set text colors, etc. by sending control characters to it.

A Windows console works differently. You may read characters from or write to it. But if you wish to move the cursor, to set text colors etc. you have to call specific system API functions with the console handle.

The Windows approach might sound more efficient. However, the most notable advantage of POSIX terminals is that as long as control characters can be delivered you really don't have to care about how they are delivered. That's why pseudo terminals are functional via SSH (and also note SSH tunneling, like Matryoshka Dolls). On Windows this would require some program to translate control character sequences into native Windows APIs, which is what MSYS2 does.

[graphixillusion]

@lhmouse thank you for the explanation. I've one question about it: why vim editor works good instead? What's the difference?

[lhmouse]

Are you referencing the MSYS2 vim?

[graphixillusion]

Nope, i use the official windows vim binary from the official website.

[E3V3A]

I came here for this exact same reason.

I install Nano using choco (which is way outdated) and when using SSH into Win10 machine it doesn't work (as stated above), but vim installed by choco install vim works fine. Too bad, because I love Nano and have made many rc files for it.

Also @lhmouse why isn't there an windows installer for this?

• Where should I put all the *.nanorc files...
• ...and the .nanorc?

[E3V3A]

@graphixillusion @lhmouse Interesting!

When I SSH into a Win10 machine with this nano.exe, I am able to navigate correctly using the arrow keys, however, while the cursor placement is wrong, the typed text appears in the correct place!

# SSH into pwsh.exe shell using: 
ssh -2 -t username@xx.xx.xx.xx "pwsh -i"

# Set the remote TERM to be "cygwin" instead of  (default) "xterm":
$Env:TERM = "cygwin"  # not needed
nano -cg .\test.txt

Hitting CTRL-L (^L in Nano language) will "Refresh (redraw) the current screen" and show current cursor location! Funny enough, F11 which is described as "^C = Display the position of the cursor" only show the position in the "bottom info bar".

So if this could be automatically executed after each character received, we would have a working Nano, also in SSH, AFAICT.

[lhmouse]

• Where should I put all the *.nanorc files...
• ...and the .nanorc?

Syntax files are loaded as specified in your primary .nanorc file. You may put them anywhere, as long as you set up the correct path to them.

As for the .nanorc file, see README.

Again: I know no curses details. I only ensure that nano builds as a native program, Ctrl, Alt, FN keys etc. work in native consoles. There's a lot of issues, such as UTF-8 not working, glitches, etc. If you work through SSH (Cygwin I presume) then I highly recommend the Cygwin or MSYS2 nano. You may build one yourself if it's out of date.

[E3V3A]

@lhmouse

Syntax files are loaded as specified in your primary .nanorc file. You may put them anywhere, as long as you set up the correct path

Yes, I know. But on Windows where is the location of .nanorc supposed to be? In your Users home directory? Under AppData?? I.e. When I run nano.exe, where is it looking for .nanorc?

[garoto]

%ALLUSERSPROFILE%

Weird, I know.

The above isn't proper, my bad. This is :

+ .nanorc is loaded from '%USERPROFILE%\.nanorc' with normal privilege
    and from "%ALLUSERPROFILE%\.nanorc" with elevated priviledge.
+ Systemwide nanorc is loaded from "%ALLUSERSPROFILE%\nanorc".

[E3V3A]

I still think the CTRL-L trick, is key here. So if we (ehh...you) can make nano repeatedly execute that subroutine after each key press, then it would work. Speaking of which. What was the original purpose of even having ctrl-L in the first place?

[E3V3A]

Any updates?

[lhmouse]

@E3V3A The issue above works on Linux because the process receives SIGWINCH when the window is resized. This signal does not exist in Windows so I have to delete related code. I have no idea about how to make it work again.

[E3V3A]

Hi @lhmouse

... The issue above works on Linux because the process receives SIGWINCH when the window is resized.

Not sure what you mean. I was not using Linux when testing, the issue (as it was described and occurred for me), was on connecting windows to windows.)

This signal does not exist in Windows so I have to delete related code...

1. Are you sure it doesn't exist? HERE are some discussions about implementations from 2017.

2. What do you mean "delete"?

[E3V3A]

Some other related issues:

• https://github.com/microsoft/terminal/issues/305
• https://github.com/ponylang/ponyc/issues/1764
• https://github.com/ponylang/ponyc/pull/1763
• https://github.com/microsoft/terminal/issues/281
• https://github.com/microsoft/terminal/issues/383

[lhmouse]

You cannot include <termios.h> on Windows. There is no such header. You should have had a look at the last commit on master (for example https://github.com/lhmouse/nano-win/commit/4e3ff45b6046b17937166d1b98355de6828307ac#diff-288cca21deb5dca702f247ebab4b7073L879; note this link is volatile).

Windows consoles work differently from Linux. On Windows you have to call ReadConsoleInput() and check for WINDOW_BUFFER_SIZE_EVENT, but on Linux it's done with the SIGWINCH signal, which cannot be replicated on Windows. If you wish to handle window resize events you have to patch ncurses (note there is already a patch for it; see files) source and assign a new return value for wgetch(). This feature may be necessary (for you and others) but I don't think it's worth having because on Windows it's uncommon to resize the buffer (not resizing the window with your mouse; this has to be done via the property dialog) while nano is active.

So, back to your original question, why there is Ctrl-L? On Linux you can put a program to background with Ctrl-Z, while it may still write to your console. Other programs can also write to your console if they have root access. This means that when you are editing a file, other programs may mess up with your screen. When this happens, you can force a redraw with Ctrl-L. Of course, on Windows this can hardly happen.

[E3V3A]

@lhmouse Thank you so much for taking the time to explain. I guess there is nothing to do then here, except try to install Cygwin or Git Bash on the remote machine, when using SSH and in case you wanna be able to use Nano.

[lhmouse]

The MSYS2 or Cygwin nano might work better with SSH.

However they do have shortages (if not bugs). For example, recently nano has gained a feature that you can backspace a word by pressing Alt-Backspace, which does not work in MSYS2 nano, not even in Mintty. Maybe it's too old; I don't remember when nano added this feature.

[eabase]

Indeed, I wish I had read this thread before!

As my other reported issues with this nano build, was driving me crazy, as everything seem to work, except syntax highlight. So I tried running the Cygwin (MSYS2) version of nano.exe, in both the pwsh.exe (Admin) console and (pwsh.exe) from inside a Windows Terminal, as normal user.

The results is that version works (with all the .nanorc files and paths from win version).
I have not tried this over SSH.

# file /usr/bin/nano.exe
PE32+ executable (console) x86-64, for MS Windows

# THIS version!
# file /cygdrive/c/mybin/wintools/nano/bin/nano.exe
PE32+ executable (console) x86-64 (stripped to external PDB), for MS Windows

# /usr/bin/nano.exe -V

 GNU nano, version 4.9
 (C) 1999-2011, 2013-2020 Free Software Foundation, Inc.
 (C) 2014-2020 the contributors to nano
 Email: nano@nano-editor.org    Web: https://nano-editor.org/
 Compiled options: --enable-utf8

# /cygdrive/c/mybin/wintools/nano/bin/nano.exe -V

 GNU nano from git, v5.9-10-gbe0fb5d4a
 (C) 1999-2011, 2013-2021 Free Software Foundation, Inc.
 (C) 2014-2021 the contributors to nano
 Compiled options: --disable-libmagic --disable-speller --disable-nls --disable-utf8

@lhmouse Because everything else (but not coloring), seem to work with your latest version, I start to think it's a UTF-8 issue.

What is the issue with UTF-8?
Perhaps you can post a detailed issue, so that we can reproduce the issue you have? Is that why you have disabled utf-8 in the compile options?

AFAIK, the entire windows-10 system has been built to automatically support UTF-8, but that there may be issues when trying to use UTF-8 files with and without BOM.

To check your current Windows locale etc, use something like:

[console]::InputEncoding && [console]::OutputEncoding && $OutputEncoding && chcp

[lhmouse]

The issue about UTF-8 is that the MSYS2 or Cygwin nano supports UTF-8 via the MSYS2 or Cygwin C runtime. But nano-win works on MSVCRT which does not support UTF-8. Legacy MSVCRT is actually a double-byte-character-string system which means a multibyte character (UTF point) can take at most 2 bytes, while in UTF-8 it's up to 4.

[eabase]

So what is the reason you're not using UCRT?

[garoto]

Oh boy...

[lhmouse]

So what is the reason you're not using UCRT?

The only reason is that this project predates the MSYS2 UCRT subsystem, and nobody has requested UCRT builds so far. If you request it, I can build it for you. Please be on topic after all.

[rkitover]

What ssh server are you using? These builds actually work perfectly over recent versions of openssh for windows, the only issue I had was with the config file location when the shell is elevated, as it is in an ssh session (#34).

You can install openssh for windows with choco like this (run this in powershell):

choco install -y powershell-core sed
stop-service ssh-agent
sc.exe delete ssh-agent
choco install -y openssh --prerelease --force --params '/SSHServerFeature /SSHAgentFeature /PathSpecsToProbeForShellEXEString:$env:programfiles\PowerShell\*\pwsh.exe'
refreshenv
sed -i 's/^[^#].*administrators.*/#&/g' /programdata/ssh/sshd_config
restart-service sshd
&(resolve-path /prog*s/openssh*/fixuserfilepermissions.ps1)
import-module -force (resolve-path /prog*s/openssh*/opensshutils.psd1)
repair-authorizedkeypermission -file ~/.ssh/authorized_keys