The first problem has been solved ，The solution is to copy by holding shift,
The problem of uploading files has not been solved.

tmux has nothing to do with uploading files.

so ，What if you need to upload files？@nicm

scp? rsync? FTP? How would I know?

Oh you want to use xmodem or zmodem. It won't work in tmux, you need to use it outside tmux.

yes,We hope to support the function of xmodems or zmodems with tmux. of course,I don't know if that's possible

why？，can you give me a doc on the principle of Tmux，thanks

It would require a lot of faff to make it work, and hardly anyone uses it anymore.

@feiyx It doesn't work because the necessary code for tmux to support the protocol transparently hasn't been written. I've been using computers since 1977. I can't even remember the last time I used zmodem it was so long ago. Even if someone was willing to write the necessary code it doesn't make sense to incur the cost to add it to tmux now.

@nicm It may be worth putting a couple of sentences in the FAQ since this is the second time I can recall seeing this feature requested (see #906).

I have added an FAQ entry.

Ignorance is not a reason to dismiss a feature request. There are lots of use cases for the transfer protocol...
Iterm on Macs support it.
Various shells on Windows support it.
It's not just about transferring files, it's about retreiving or updating text files quickly...

My take on this feature request is not to plumb tmux with the protocols, but to code tmux so it gets out of the way of the protocol. RHEL, fedora and other distributions already provide the protocol via the lrzsz package, and a user initiates the transfers via the commands sz and rz.

Tmux gets in the way of the transfer initiation bytes written to the terminal or the following stream of bytes.

@therevoman, You wrote:

It's not just about transferring files, it's about retreiving or updating text files quickly...

I can't grok your comment since retrieving/updating files in that fashion is equivalent to "transferring" files between two systems. Also, iTerm does not support zmodem directly. It simply makes it possible via its "trigger" facility that allows arbitrary actions when a specific sequence of bytes is seen.

Adding something like screen's zmodem [pass | off] command is not unreasonable. Although I would name it something else to make it clear it is simply a means for telling tmux to not interpret any subsequent bytes; i.e., be transparent to any bytes sent or received. Perhaps passthru [on | off]. Feel free to create a pull-request -- assuming @nicm isn't opposed to adding a user controlled passthru mode. In any case adding the actual file transfer protocol to tmux is still a bad idea.

tmux how to upload files，like bash rzsz this

哥们儿，好多年就用上tmux，因为lrzsz放弃，至今没再用过tmux

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.