I'm working on a raspberry pi, and trying to paste some text files into a command-line text editor nano... but the text ends up corrupted on the remote end (partial/incomplete text). I can only guess the paste function of my PC (xubuntu 16.04) is pushing the data too fast (the serial baud is 115200).

Can I slow down the paste function somehow?

  • p.s. I'm using picocom
    – nmz787
    Feb 28 '20 at 11:29
  • 1
    I'm using a first-gen pi, it has no wifi or bluetooth, and I don't want to add a USB hub or setup wpa_supplicant and ssh_server just to modify a little bit of code for this headless pressure/temperature gauge application
    – nmz787
    Feb 28 '20 at 12:17
  • I found an answer that worked perfectly, it seems your understanding of application-layer pasting is incorrect.
    – nmz787
    Feb 29 '20 at 7:26
  • No, my understanding is correct. At least for me, it's OK if you use this Q&A platform to promote some cool hack you wrote or found on the internet, but please be clear about it (so people don't naively assume you had a real problem and try to help you, as I did) and refrain from making ridiculously patronizing considerations.
    – mosvy
    Feb 29 '20 at 7:29
  • Hey if you have an answer, feel free to add one. Otherwise, it seems totally logical to me that the terminal GUI program being pasted into controls the rate at which that is passed to the serial port. I'd be glad for you to provide legit info disproving this, but case in point, screen has a feature called slowpaste.
    – nmz787
    Mar 1 '20 at 10:55

I found that screen has a slowpaste function! https://gist.github.com/jandahl/8436cd6a99d56efd9ff4

  1. install screen

  2. make a .screenrc file if you don't have one:

startup_message off

hardstatus alwayslastline
hardstatus string '%{= kG}[ %{G}%H %{g}][%= %{= kw}%?%-Lw%?%{r}(%{W}%n*%f%t%?(%u)%?%{r})%{w}%?%+Lw%?%?%= %{g}][%{B} %m-%d %{W}%c %{g}]'

defslowpaste 20 ## It is the value to the left that is the central one for your happiness
  • if you already have a .screenrc then just add the last line: defslowpaste 20

  1. start screen with the appropriate serial port (raspberry pi, first gen, defaults to 115200 baud): screen /dev/ttyUSB3 115200

  2. Have fun!


I can only guess the paste function of my PC (xubuntu 16.04) is pushing the data too fast (the serial baud is 115200).

That assumption is wrong. The terminal driver will always write through the data from its output queue with the configured baud rate, and a write(2) to the terminal will either return a short count, or block if there's no more space in the output queue (or instead of blocking, will return -1 and set errno to EAGAIN if the terminal is set in non-blocking mode). The serial driver will not "adapt" the baud rate to how much data it has to push through.

You can easily test that if you have two machines which can be connected via a serial line (or you could connect the same machine to itself, eg. 2 USB->serial adapters, two serial ports connected via a null-modem cable, etc).

Eg. if /dev/ttyUSB0 on machine A is connected to /dev/ttyUSB1 on machine B:

On machine A:

# stty -F /dev/ttyUSB0 speed 50 raw; cat /dev/ttyUSB0

On machine B:

stty -F /dev/ttyUSB1 speed 50 raw opost onlcr; cat >/dev/ttyUSB1

Now, paste some large text in the command line on machine B, and see it nicely trickle down at the speed of ~5 characters per second on machine A.

The real problem is with brogrammers which ignore the exit status of write(2) or assume that while it can return an error, it will never a return a count less than required. The solution is to fix or stop using their junk, not to use band-aids which are neither reliable nor very effective.

Also, if the cable/connections are bad/noisy, you will have to lower the baud rate, otherwise the data will turn into binary junk, and some serial-adapters may lock hard and have to be reset.

The baud rate should also be lowered if one of the devices is not able to cope with its nominal baud rate, and doesn't support any kind of hardware or software flow control (xon/xoff).

  • This isn't an actionable answer to the problem, though it's an interesting procedure for root-causing. Thanks for the explanation... If I hit the issue again, I'll review again and try this. Seems like your TL;DR/action item is to slow the baud rate.
    – nmz787
    Mar 2 '20 at 12:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.