Built-in linux terminal crashes when pasting 39-character string into nano

[dcmills2]

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: 1.77.3
• OS Version: Ubuntu 20.04.6

Steps to Reproduce:

1. Launch VSCode on an Ubuntu computer (or on Windows using WSL)
2. Enter the built-in terminal
3. Run the command nano
4. Copy and paste the following 39-character string into nano: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
5. Result: nano shows the error message "Unknown Sequence". Can no longer interact with the terminal, need to kill it and open a new one

More details:

• nano version 4.8
• This does not happen in nano using an external terminal. Only in VSCode's built-in terminal
• This does not happen for any other length of string, even other multiples of 39
• This does not happen in other CLI text editors, such as vim

[samuelphy]

I can confirm this issue on Windows using WSL.

[supa-freak]

It happens with other 39 long strings as well. It also happens when not using WSL. Copying more characters solves the problem.
For us it also happens with multiples of 39 (e.g. 156 characters, line breaks included)

[Tyriar]

When trace logs are enabled this is the exact sequence we send:

"\u001b[200~aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\u001b[201~"

Compared to 1 less a:

"\u001b[200~aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\u001b[201~"

Note that the 200/201 wrapped around it is bracketed paste mode (which I just added a way to disable so that may help #189480). So this seems to be either a problem with one of nano, conpty or node-pty.

[addmitt]

I also just ran into this. I'm on Windows 10, using Remote - SSH plugin to connect to an Ubuntu 22.04 server. Right-click to paste in Nano, terminal locks up, have to Kill it. Add/remove one character from the string and try again, works.

[vscodenpa]

We closed this issue because we don't plan to address it in the foreseeable future. If you disagree and feel that this issue is crucial: we are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding, and happy coding!

[programmerjake]

i opened a bug on gnu nano's bugtracker: https://savannah.gnu.org/bugs/index.php?64996

[programmerjake]

I think I found a workaround, but haven't tested it: vscode intentionally splits terminal writes into at most 50-byte chunks, nano doesn't deal well with escape sequences being split across writes and it is apparently difficult to fix in nano.

vscode could split writes differently, using this algorithm that keeps escape sequences at the beginning and end unsplit (like bracketed pastes):

const num_chunks = Math.ceil(data.length / Constants.WriteMaxChunkSize);
if (num_chunks == 1) {
    write(data);
} else if (num_chunks == 2) {
    const split_point = Math.floor(data.length / 2);
    write(data.substr(0, split_point));
    write(data.substr(split_point));
} else if (num_chunks > 2) {
    const stop = data.length - Constants.WriteMaxChunkSize;
    for (let i = 0; i < stop; i += Constants.WriteMaxChunkSize) {
        const size = Math.min(stop - i, Constants.WriteMaxChunkSize);
        write(data.substr(i, size));
    }
    write(data.substr(stop));
}

[Tyriar]

@programmerjake great info, we should definitely do this 👍. I'll probably tweak your proposal a little to try catch escape sequences in the middle too.

[programmerjake]

I don't expect input sizes to be > 50 bytes except when pasting, when pasting there should only ever be an escape sequence at the beginning and end, never in the middle (terminal apps are unlikely to deal well with pasting a string containing escape sequences anyway).

[Tyriar]

@programmerjake unless I missed something in the issue you linked, it's not that they need to be on the boundaries of the text but need to be included entirely in that string and not clipped?

[programmerjake]

@programmerjake unless I missed something in the issue you linked, it's not that they need to be on the boundaries of the text but need to be included entirely in that string and not clipped?

yes, escape sequences need to be contained entirely in one write syscall. basically I am saying you shouldn't have escape sequences in the middle of a long input, so you don't need to look for them to avoid splitting them, they should only occur towards the ends of a long input or in a shorter input.

[programmerjake]

Nano's workaround was released in Nano 8.0: https://savannah.gnu.org/bugs/?64996#comment14