I created rcp, an OSC52 copy tool for your remote server (codeberg.org)
from Black616Angel@feddit.de to rust@programming.dev on 31 Mar 12:42
https://feddit.de/post/10585019

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.

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) 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, they have a nice list.

#rust

threaded - newest

onlinepersona@programming.dev on 31 Mar 16:00 next collapse

Intriguing 🤔 Might actually come in handy. Thank you!

CC BY-NC-SA 4.0

madmo@programming.dev on 31 Mar 16:59 next collapse

Thanks for creating and sharing this tool! Will definitely add it to my toolbelt!

RunAwayFrog@sh.itjust.works on 31 Mar 17:13 next collapse
  • 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?
Black616Angel@feddit.de on 31 Mar 19:13 collapse

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.

RunAwayFrog@sh.itjust.works on 31 Mar 19:55 next collapse

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 ;)

Corbin@programming.dev on 01 Apr 04:10 collapse

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.

crispy_kilt@feddit.de on 01 Apr 12:30 collapse

TIL about OSC52, this is very good to know, thank you for sharing!