I created rcp, an OSC52 copy tool for your remote server
I created rcp, an OSC52 copy tool for your remote server
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.
- Don't use
"*"dep version requirements. - Add
Cargo.lockto version control. - Why read to string if you're going to base64-encode and use
Vec<u8>later anyway?
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.
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.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 arust-toolchainfile is tracked by version control, and is pinned to a specific stable release, thenCargo.lockshould 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
--lockednot being the default behaviour ofcargo 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 trackingCargo.lock;)
- Don't use
TIL about OSC52, this is very good to know, thank you for sharing!
Thanks for creating and sharing this tool! Will definitely add it to my toolbelt!
Intriguing 🤔 Might actually come in handy. Thank you!