4 ms·
What to do instead: Use Nushell. I finally started really using my shell after switching to it. I casually write multiple scripts and small functions per day t
by Aerbil313 2y ago
What to do instead: Use Nushell.
I finally started really using my shell after switching to it. I casually write multiple scripts and small functions per day to automate my stuff. I'm writing scripts I'd otherwise write in python in nu. All because the data needs no parsing. I'm not even annotating my data with types even though Nushell supports it because it turns out structured data with inferred types is more than you need day-to-day. I'm not even talking about all the other nice features other shells simply don't have. See this custom command definiton:
# A greeting command that can greet the caller
def greet [
name: string # The name of the person to greet
--age (-a): int # The age of the person
] {
[$name $age]
}
Here's the auto-generated output when you run `help greet`:
A greeting command that can greet the caller
Usage:
> greet <name> {flags}
Parameters:
<name> The name of the person to greet
Flags:
-h, --help: Display this help message
-a, --age <integer>: The age of the person
It's one of the software that only empowers you, immediately, without a single downside. Except the time spent learning it, but that was about a week for me. Bash or fish is there if I ever need it to paste some shell commands.
- db48x 2y agoParsing, or the lack thereof, is not the point. The point is that standard shells already provide all the tools you need for dealing with lists of files. Want to do something for every file? Write this: shopt -s nullglob for f in *; do … done But never this: for f in $(ls); do … done They look similar, but the latter runs ls to turn the list of files into a string, then has the shell parse the string back into a list. Even if the parsing was done correctly (and it isn’t), this is still extra work. Looping over the glob avoids the extra work.
- Aerbil313 2y agoI have to say this is very unintuitive. In Nushell, you'd do: ls | each { ... } Another examples I don't need to explain, which would be far harder in stringly typed shells: ls | where type == file and size <= 5MiB | sort-by size | reverse | first 10 ps | where cpu > 10 and mem > 1GB | kill $in.pid It's immediately obvious what you need to do when you can easily visualize your data: > ls ╭────┬───────────────────────┬──────┬───────────┬─────────────╮ │ # │ name │ type │ size │ modified │ ├────┼───────────────────────┼──────┼───────────┼─────────────┤ │ 0 │ 404.html │ file │ 429 B │ 3 days ago │ │ 1 │ CONTRIBUTING.md │ file │ 955 B │ 8 mins ago │ │ 2 │ Gemfile │ file │ 1.1 KiB │ 3 days ago │ │ 3 │ Gemfile.lock │ file │ 6.9 KiB │ 3 days ago │ │ 4 │ LICENSE │ file │ 1.1 KiB │ 3 days ago │ │ 5 │ README.md │ file │ 213 B │ 3 days ago │ ...
- db48x 2y agoI didn’t say that nushell is bad, I said that it’s not relevant to the discussion. nushell provides typed data in pipelines, which is cool. But standard shells already have typed data for this particular use case, thus parsing untyped data is unnecessary. Of course it would be nice if that typed data could be used in a pipeline, but everything had to start somewhere.
- acureau 2y agoWho are you to decide what's relevant to the discussion? It's very clearly on topic. I had never heard of nushell and I'm glad it was mentioned
- CJefferson 2y agoHow do I replace: for f in $(cd subdir; ls); do ... done ?
- ykonstant 2y agoEither for f in subdir/*; do ... done or ( cd subdir || exit 1 for f in *; do ... done ) work fine. However, I must insist against using `for` loops in favor of `find`.