rustup.rs | hck | |
---|---|---|
1 | 15 | |
0 | 683 | |
- | - | |
10.0 | 4.6 | |
over 5 years ago | 26 days ago | |
Rust | Rust | |
Apache License 2.0 | The Unlicense |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
rustup.rs
-
Ask HN: Let's Build CheckStyle for Bash?
Much of the time that people are writing shell scripts, they're writing them not because they prefer shell syntax to that of some other language, but rather because they're creating a script that needs to be widely disseminated/deployed to all sorts of machines with unpredictable install bases.
This is why a large fraction of the shell scripts that exist in the world still hold to Bourne shell syntax, rather than using any of the syntax extensions from its descendant shells — Bourne shell (or at least, something at /bin/sh that interprets Bourne-shell syntax) is part of the POSIX standard. So you can expect any POSIX system — no matter how weird — to be able to run (Bourne) shell scripts. You can run them on Alpine. You can run them on Busybox. You can run them on your NAS. You can run them on your router. You can run them in your initramfs, on your Kubernetes nodes, on your Mosix nodes, whatever.
For an example of the type of script I'm talking about — see e.g. the script you download+run when you run the command-line on https://rustup.rs: https://github.com/hsivonen/rustup.rs/blob/master/rustup-ini...
There's absolutely no benefit that this script gets from being written directly in POSIX-compiliant Bourne shell syntax, rather than being written in something that compiles to it; any more than programs for your PC would benefit from being written directly in ASM rather than in something that compiles to it.
hck
- An old but good field command for printing tab separated fields from a file to stdou.t
-
What is yay situation?
hck ["hck" in community repo] - a fancier cut with regex field delimiters
-
What are your favorite Rust-powered Linux programs?
Biased because it's my tool, but I do use it every day! hck - which is like cut, but much faster and with a tidier set of features.
-
Tuc – When cut doesn’t cut it
hck - close to drop in replacement for cut that can use a regex delimiter instead of a fixed string
-
Tuc – when cut doesn’t cut it
Nice, especially the format output.
See also:
* hck (https://github.com/sstadick/hck) - close to drop in replacement for cut that can use a regex delimiter instead of a fixed string
* rcut (https://github.com/learnbyexample/regexp-cut) - my own bash+awk script, supports regexp delimiters, field reordering, negative indexing, etc
- csvlens: Command line CSV file viewer
-
Ask HN: Let's Build CheckStyle for Bash?
You might want to check out 'hck' to replace 'cut'.
https://github.com/sstadick/hck
- hck v0.6.6: > 24% performance improvements on common workloads
- Show HN: Hck – a fast and flexible cut-like tool
What are some alternatives?
shfmt - A shell formatter (sh/bash/mksh)
sd - Intuitive find & replace CLI (sed alternative)
shfmt - Dockernized shfmt. This formats shell script.
csvlens - Command line csv viewer
bashate - Code style enforcement for bash programs. Mirror of code maintained at opendev.org.
nlpo3 - Thai Natural Language Processing library in Rust, with Python and Node bindings.
murex - A smarter shell and scripting environment with advanced features designed for usability, safety and productivity (eg smarter DevOps tooling)
UNIC - UNIC: Unicode and Internationalization Crates for Rust
ripgrep - ripgrep recursively searches directories for a regex pattern while respecting your gitignore
tuc - When cut doesn't cut it
regexp-cut - Use awk to provide cut like syntax for field extraction
fd - A simple, fast and user-friendly alternative to 'find'