Black616Angel

I created rcp, an OSC52 copy tool for your remote server

https://feddit.de/post/10585019

I created rcp, an OSC52 copy tool for your remote server - Feddit

I have been searching for a simple way to copy loads of text from remote servers for a while. This includes files, but is sometimes also only multiple lines from stdout of a program. Oftentimes this is kinda hard to do in terminal emulators, so I wrote a very small program to copy text via Operating System Commands [https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h3-Operating-System-Commands]. This allows the terminal emulator itself to copy the text directly into the host clipboard. No x11 pass-through needed. Lots of text editors like vim (with oscyank-plugin [https://github.com/ojroques/vim-oscyank]) or helix already have a functionality like that, but opening large files just to copy them is stupid (also not all servers I admin have the oscyank or helix even installed). If you want to know, if your terminal emulator supports osc52, please refer to the oscyank-repo [https://github.com/ojroques/vim-oscyank], they have a nice list.

Mar 31, 2024 at 12:42pmWeb
Show threadonlinepersonaMar 31, 2024

Intriguing 🤔 Might actually come in handy. Thank you!

CC BY-NC-SA 4.0

Deed - Attribution-NonCommercial-ShareAlike 4.0 International - Creative Commons

Show threadmadmoMar 31, 2024
Thanks for creating and sharing this tool! Will definitely add it to my toolbelt!
Show threadRunAwayFrogMar 31, 2024
  • Don’t use “*” dep version requirements.
  • Add Cargo.lock to version control.
  • Why read to string if you’re going to base64-encode and use Vec<u8> later anyway?
Show threadBlack616AngelMar 31, 2024

All good points. I will address them in a later version.

The Cargo.lock thing is weird though, but apparently the builtin .gitignore of codeberg/forgejo has Cargo.lock in it.

Show threadRunAwayFrogMar 31, 2024

Regarding Cargo.lock, the recommendation always was to include it in version control for application/binary crates, but not library ones. But tendencies changed over time to include it even for libraries. If a rust-toolchain file is tracked by version control, and is pinned to a specific stable release, then Cargo.lock should definitely be tracked too [1][2].

It’s strictly more information tracked, so there is no logical reason not to include it. There was this concern about people not being aware of –locked not being the default behaviour of cargo install, giving a false sense of security/reliability/reproducibility. But “false sense” is never a good technical argument in my book.

Anyway, your crate is an application/binary one. And if you were to not change the “*” dependency version requirement, then it is almost guaranteed that building your crate will break in the future without tracking Cargo.lock ;)

Change in Guidance on Committing Lockfiles | Rust Blog

Empowering everyone to build reliable and efficient software.

Show threadCorbinApr 1, 2024
In addition to the sibling comment, note that reproducible build systems from Docker to Nix require a lockfile in order to be reproducible, and if you don’t provide one, then somebody downstream will provide it instead. By checking in Cargo.lock, you ensure control over the precise versions of your dependencies for all downstream users.
Show threadcrispy_kiltApr 1, 2024
TIL about OSC52, this is very good to know, thank you for sharing!