I created rcp, an OSC52 copy tool for your remote server (codeberg.org)

submitted 9 months ago by Black616Angel@feddit.de to c/rust@programming.dev

7 comments fedilink hide all child comments

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.

top 7 comments

sorted by: hot top controversial new old

[-] RunAwayFrog@sh.itjust.works 8 points 9 months ago

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 1 points 9 months ago

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.

[-] Corbin@programming.dev 5 points 9 months ago

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.

[-] RunAwayFrog@sh.itjust.works 4 points 9 months ago

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