Nano via secure shell session from a MS windows computer freezes

dsmythies · February 22, 2025, 10:32pm

While using nano to edit a file on my Ubuntu 24.04.1 test server, nano will sometimes freeze after a paste. The server is headless, and communication is via secure shell from a MS Windows 11 computer via OpenSSH_for_Windows_9.5p1. I have to close the terminal session in windows and start again, often loosing the edits done prior to the freeze.

I have tried every keystroke I can think of to try to get the session unfrozen, but so far nothing has worked.

As far as I can determine the nano task seems to still be running. In the below example, there are 2 nano session running, one is frozen and one is not:

doug@s19:~$ ps -eo tid,class,ni,pri,psr,pcpu,stat,wchan:14,comm | grep -e nano -e bash
 644876 TS    0  19   1  0.0 Ss   do_wait        bash
 644888 TS    0  19   2  0.0 S+   wait_woken     nano
 644938 TS    0  19   6  0.0 Ss   do_wait        bash
 647126 TS    0  19  11  0.0 Ss   do_wait        bash
 675011 TS    0  19   1  0.0 S+   wait_woken     nano

How do I know the problem is on the Ubuntu side? I don’t, and am pursuing the issue from the windows side also. Regardless, if there is some way to “kick” things out from being frozen it would very useful.

Note 1: PuTTY 0.83 was installed and tried as the SSH client, and the issue did not occur. I prefer the windows SSH client over PuTTY.

Note 2: I think, but am not certain, the issue occurs when numbers are copied and pasted into nano session. I do not know how to reliably create the issue, but I do have a simplified file where it always occurs:

and:
nano-freeze-bell

EDIT: putting that same file onto a raspberry pi, via rsync and then using nano (version 3.2) there worked fine.
EDIT: putting that same file onto a Debian server, via rsync and then using nano (version 5.4) there worked fine. CORRECTION: FAILS
The version on my 24.04 server is 7.2
EDIT: putting that same file onto a Ubuntu 24.10 VM running on the Debian server, via rsync and then using nano (version 8.1) there worked fine. Note that while trying to paste “10000” it actually pasted “10000~”.
EDIT: putting that same file onto a Ubuntu 24.04.2 VM running on the Debian server, via rsync and then using nano (version 7.2) there failed.

EDIT: I installed the nano 8.3-1 package from launchpad. It still has the “10000~” instead of “10000” issue, but at least it doesn’t freeze.

I believe there are 2 issues here: First, Either windows or windows SSH puts extra characters into the clipboard buffer or inserts them during paste; Second, some versions of nano don’t deal well with those characters.

Link to this same issue on Win32-OpenSSH-GitHub page

dsmythies · February 27, 2025, 11:17pm

Pasting a different sized paste buffer will work to unfreeze the frozen session.

Using a newer version of nano will prevent the freeze in the first place, but currently leaves a lingering “~” character.

With very good help from one of the maintainers, work is ongoing upstream at the master code site for nano.

https://lists.gnu.org/archive/html/nano-devel/2025-02/msg00001.html

Actionparsnip · February 28, 2025, 5:33pm

Is it the same in vi?

dsmythies · February 28, 2025, 7:02pm

I don’t know about vi.

The root issue has to do with “bracketed pastes”. In the incoming character stream a bracketed paste is started with “ESC [200~” (the “begin of pasted text” sequence) and terminated with “ESC [201~” (the “end of pasted text” sequence)(where the space character is just for clarity there). For whatever reasons, in nano and for certain paste buffer sizes, the trailing “end of pasted text” sequence is being split, causing confusion.

The investigation is ongoing, and the principal maintainer of nano has been very generous with his time.

EDIT: Links for interested readers to further details (two are repeats):
https://savannah.gnu.org/bugs/index.php?66858
https://lists.gnu.org/archive/html/nano-devel/2025-02/msg00001.html

github.com/PowerShell/openssh-portable

Increase stdin chunksize from 16 to 1024 chars

PowerShell:latestw_all ← lhecker:stdin-chunk-size

opened 03:07PM - 20 Dec 24 UTC

lhecker

+79 -21

# PR Summary This bumps the chunk size for `stdin` from 16 to 1024 chars. …## PR Context It would be very unusual to `read()` from a file with a 16-byte buffer. The same is true for `stdin`, but counter-intuitively it's actually a lot "more true" for `stdin` than it would be for any file: Since the `stdin` pipe is unbuffered and synchronous, the round-trip overhead for reading from it is exorbitantly high. To put it into perspective, on Windows the call overhead alone is roughly the same as subsequentially reading in the order of 100K characters. The increased buffer size has an immediately noticeable effect on the interactive shells I've tested. Pasting content into a prompt now appears immediately and atomically, while previously it would only progressively arrive and get syntax highlighted repeatedly (= flicker). Another nice benefit is that some shells have trouble determining whether an escape character is a sequence inducer or a lone escape character. Increasing the buffer size reduces the chance for hitting this edge case from 1/16th (6%) to 1/1024th (0.1%) and makes it very unlikely to occur at all for inputs <1024 characters. This issue is what prompted me to make this modification.

Actionparsnip · March 5, 2025, 7:55am

Then try it. Instead of using nano, use vi.
You can exit the editor by pressing ESC then typing

:q!

If you want to save and quit then type

:wq!

dsmythies · March 5, 2025, 4:44pm

As far as I can determine, vi works fine. I do not know if vi uses bracketed-paste mode or not.

dsmythies · March 10, 2025, 11:36pm

A solution for this issue has been committed to the master nano git code by the main nano maintainer, who has worked very very hard on it. It will take awhile for an upstream release and then even longer for it to trickle down to Ubuntu. In the meantime, I’ll just use the upstream master.

system · March 13, 2025, 11:36pm

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.