bugGNU Screen - Bugs: bug #35862, Corrupted data in Copy/Paste using...

 
 

bug #35862: Corrupted data in Copy/Paste using mouse

Submitter:  marco bernardi <bernx_alice_it>
Submitted:  Fri 16 Mar 2012 12:16:47 PM UTC
   
 
Category:  User Interface Severity:  3 - Normal
Priority:  * 5 - Normal Status:  Confirmed
Privacy:  Public Assigned to:  None
Open/Closed:  Open Release:  4.0.3
Fixed Release:  None Planned Release:  None
Work Required:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 07 May 2018 08:35:44 PM UTC, comment #3: 

Thanks for instructions, confirmed.

Amadeusz Sławiński <amade>
Group administrator
Sun 29 Apr 2018 09:07:33 PM UTC, comment #2: 

Small typo in previous comment regarding the final value of N in octave for testscript.m: it is N=50005000 of course. By Gauss' summation formula or by direct check: executing

octave --no-gui --persist testscript.m


and then typing N<return> at the octave command prompt.

Adrian <adaerr>
Sun 29 Apr 2018 05:22:31 AM UTC, comment #1: 

This bug seems to have been around forever (Bug report from 2004 on the Debian bug tracker at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=286063 ), is very easy to reproduce, quite annoying to say the least (data loss), yet does not even have the status confirmed... So I add few more test results and a simple recipe to reproduce:

1) Take some large text file (say 1e4 lines) or generate one:

(echo "N=0;"; for n in {1..10000}; do echo "N+=$n;"; done) >testscript.m


2) Open that file in your favorite text editor and select everything
3) Launch an xterm
4) Launch a screen session:

exec screen $SHELL


(exec may be omitted without affecting the result)
5) Type

cat >foobar


6) Paste the selection into the terminal by mouse-middle-button
7) Return to the command prompt by typing Ctrl-d to end cat
8) Type

diff testscript.m foobar


Expected result
No difference

Observed behaviour
Sporadic differences showing that some pasted characters where never received by cat

Example:

$> diff testscript.m foobar
3365c3365
< N+=3364;
---
> N+=336
4674c4674
< N+=4673;
---
> N+=73;
6495c6495
< N+=6494;
---
> =6494;
8258,8259c8258
< N+=8257;
< N+=8258;
---
> N+=8257N+=8258;


- Note that if you skip step 4 then step 8 shows no difference between the original and the pasted file.

- The following terminals and shells where tried:
Terminal: xterm, UXTerm, Xfce Terminal
Shell: zsh, bash
In all combinations pasting succeeds without error when no screen is started. In all combinations starting a screen session and pasting produces random input loss with the above 'cat' test.

- Alternatively you can launch nano, vim, emacs -nw.  The buffer saved from the text editors will be different from the pasted data.

- Still as an alternative to step 5, you can launch

octave --no-gui --no-history


The test script given above contains valid octave commands and should lead to a final value N=5000050000. Type N<return> at the octave prompt to show the value of N after pasting. When octave is run under screen, the value of N is less than expected final result, showing that some instructions were not processed. Note also that the command counter in the prompt will be smaller than the number of lines you pasted.

System:
Up-to-date Debian/testing GNU/Linux
Screen version 4.06.02 (GNU) 23-Oct-17
Kernel 4.15.0-2-amd64

Adrian <adaerr>
Fri 16 Mar 2012 12:16:47 PM UTC, original submission:  

when I copy/paste large block using mouse, screen loose characters and/or corrupt data

example (test done in Ubuntu and CentOS)
1) this works. test done in Ubuntu and Centos
open terminal using gnome-termonal or Putty
call vim
copy 900 lines (80 chars) from Excel sheet
paste them in vim

2) this doesn't work
open terminal using gnome-termonal or Putty
call screen
call vim
copy 900 lines (80 chars) from Excel sheet
paste them in vim -> only some lines are copied and some of them are corrupted

3) this work
open terminal using gnome-termonal or Putty
call screen
call vim
copy 100 lines (80 chars) from Excel sheet
paste them in vim

"C-a : readbuf filename" with same data I copied/pasted works perfectly

May be a problem with keyboard buffer size ?

marco bernardi <bernx_alice_it>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by amade (Posted a comment)
  • -email is unavailable- added by adaerr (Posted a comment)
  • -email is unavailable- added by bernx_alice_it (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-05-07 amade StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code