Bug description
I am using WebSSH v31.6.1716 from TestFlight. I installed the TestFlight build hoping it might resolve this problem. I think the issue first appeared for me approximately three to six months ago, but I am not certain of the exact version.
When I paste long multi-line commands using:
… → Paste → Allow Paste
long multi-line commands when pasted, overwrite previously printed terminal lines before I press Return and in their own printed output.
The pasted command appears highlighted with a white background and black text. The issue seems most likely when long pasted lines wrap beyond the right edge of the screen.
This makes it difficult to verify what command is actually about to be executed.
This may be related to, or a regression from, the previous paste/bracketed paste issues #1356 and #1432.
A temporary workaround in bash is:
bind 'set enable-bracketed-paste off'
However, my usual shell is zsh, and this does not address the underlying WebSSH paste behaviour.
The following technical detail was written with ChatGPT to help identify the possible root cause.
With bracketed paste enabled, a single paste should produce one opening marker and one closing marker:
^[[200~
[pasted payload]
^[[201~
In WebSSH, a single long paste can produce a second ^[[200~ marker inside the first paste, before the closing ^[[201~ marker. I also tested with a raw-byte capture script, and the remote process received flattened/spliced input with most newlines missing. This suggests the pasted input may be corrupted before shell interpretation, not only visually repainted incorrectly.
Steps to reproduce
-
Open WebSSH on iOS/iPadOS.
-
Connect to a remote host over SSH. In my case, the remote host is macOS using zsh.
-
Run:
printf '\033[?2004h'
cat -v
-
Use … → Paste → Allow Paste.
-
Paste a long multi-line block containing lines long enough to wrap on the mobile display.
-
Observe the pasted text before pressing Return.
Expected result:
The pasted text should remain in order, preserve newlines, and not overwrite previous terminal output. With bracketed paste enabled, there should be exactly one ^[[200~ marker and one ^[[201~ marker.
Actual result:
The pasted text can overwrite previous terminal output, lose or splice newlines, and sometimes show nested/duplicated bracketed paste markers during a single user paste.
Bug description
I am using WebSSH v31.6.1716 from TestFlight. I installed the TestFlight build hoping it might resolve this problem. I think the issue first appeared for me approximately three to six months ago, but I am not certain of the exact version.
When I paste long multi-line commands using:
…→Paste→Allow Pastelong multi-line commands when pasted, overwrite previously printed terminal lines before I press Return and in their own printed output.
The pasted command appears highlighted with a white background and black text. The issue seems most likely when long pasted lines wrap beyond the right edge of the screen.
This makes it difficult to verify what command is actually about to be executed.
This may be related to, or a regression from, the previous paste/bracketed paste issues #1356 and #1432.
A temporary workaround in bash is:
However, my usual shell is zsh, and this does not address the underlying WebSSH paste behaviour.
The following technical detail was written with ChatGPT to help identify the possible root cause.
With bracketed paste enabled, a single paste should produce one opening marker and one closing marker:
In WebSSH, a single long paste can produce a second
^[[200~marker inside the first paste, before the closing^[[201~marker. I also tested with a raw-byte capture script, and the remote process received flattened/spliced input with most newlines missing. This suggests the pasted input may be corrupted before shell interpretation, not only visually repainted incorrectly.Steps to reproduce
Open WebSSH on iOS/iPadOS.
Connect to a remote host over SSH. In my case, the remote host is macOS using zsh.
Run:
Use
…→Paste→Allow Paste.Paste a long multi-line block containing lines long enough to wrap on the mobile display.
Observe the pasted text before pressing Return.
Expected result:
The pasted text should remain in order, preserve newlines, and not overwrite previous terminal output. With bracketed paste enabled, there should be exactly one
^[[200~marker and one^[[201~marker.Actual result:
The pasted text can overwrite previous terminal output, lose or splice newlines, and sometimes show nested/duplicated bracketed paste markers during a single user paste.