Rust

6009 readers

2 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

[email protected]

Credits

The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 1 year ago

MODERATORS

[email protected]

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

submitted 7 months ago by [email protected] to c/[email protected]

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.

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 9 points 7 months ago (3 children)

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?

[–] [email protected] 1 points 7 months ago (2 children)

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.

[–] [email protected] 4 points 7 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 ;)

load more comments (1 replies)