Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nushell.sh ls | where size > 10mb | sort-by modified

nushell.sh

Post reply on HN
Print view View original

171–180 of 215 posts

Re: Nushell.sh ls | where size > 10mb | sort-by modified

#171

Post by nailer »

jedisct1 wrote: post #52

I tried to use it as my main shell for a couple days, found it fun and potentially useful, played with its unique features... and eventually uninstalled it and went back to zsh. For 99.99% of what I use a shell for, Nushell doesn't do anything that I can't do with a regular shell. Maybe just because I'm used to shells/sed/awk/etc. For the few cases where Nushell could be useful, I can usually do the same thing with V…

> Maybe just because I'm used to shells/sed/awk/etc.

I suspect we’re both great at regexs. But scraping is brittle and trying to use it with object shells defeats the purposes.

Re: Nushell.sh ls | where size > 10mb | sort-by modified

#172

Post by phist_mcgee »

jrumbut wrote: post #161
stingraycharles wrote: post #98

Earlier quoted context omitted.

Isn’t this the problem with older shells as well? Eg you have to use e.g. awk or sed to deal with more complicated text processing. My understanding that the biggest difference between powershell (and nushell) and the older bash-like shells is that they deal with structured, object-like data rather than text. How would things be any different when “things break down” vs an older shell?

One of the nice things about bash is that it interacts very nicely with Perl and Ruby. I wonder how these other shells work with the backticks and such in Perl/Ruby. Theoretically there is room for very cool interoperability but I wonder how it goes in practice and if any nice tools and patterns are being developed.

Since this is nushell and perl and ruby are now starting to be considered 'old, is that so much of a problem?

Re: Nushell.sh ls | where size > 10mb | sort-by modified

#173

Post by nailer »

bsg75 wrote: post #135
shortrounddev wrote: post #71

I like the idea of piping structured data between processes instead of streams of bytes, but that's what PowerShell is for. I don't think I've ever met another dev who likes PowerShell

> I don't think I've ever met another dev who likes PowerShell I have. But they have never used bash, zsh, Fish, or NuShell.

I’ve been using bash for 25 years and like powershell. I like nushell more though (for the reasons the sibling comment mentioned).

Re: Nushell.sh ls | where size > 10mb | sort-by modified

#174

Post by nailer »

Diti wrote: post #153
bsg75 wrote: post #135

Earlier quoted context omitted.

> I don't think I've ever met another dev who likes PowerShell I have. But they have never used bash, zsh, Fish, or NuShell.

I use Zsh at home, and PowerShell 5 (for DSC 1.1) and 7 at work. I love both. I would almost be tempted to use pwsh as my main shell on Linux, but I am too attached to Zsh’s amazing RPROMPT!

I don’t know about rprompt but check out oh-my-pwsh

Re: Nushell.sh ls | where size > 10mb | sort-by modified

#175

Post by pxc »

e12e wrote: post #158
pxc wrote: post #112

Earlier quoted context omitted.

`save` seems to be a general serialization command, which lets you save Nu objects in formats like JSON, YAML, and others. The `--raw` option seems like a convenience for enabling that tee-like usage without relying on external programs, but the driving use case is serializing structured data rather than unstructured text or byte streams.

Ah, I failed to realize that nushell deals with rich data. I think this might hit the sweetspot for me, for dealing with json - I never could get a feel for "jq" like I have with sed/awk, and don't much enjoy powershell. I don't think I need a new shell (bash is fine - and I would probably move to fish for a new shell if I were to change) - but I certainly need a sane way to wrangle json (hello docker inspect!) and y…

FWIW, I've made basically the same call for now: Fish has been my daily driver for some time, but I have a lot of interest in Nushell and some real affection for Elvish, and I think I'd like to eventually make the switch to one of these newfangled shells with the structured pipelines one day.

The great thing about shell languages is that you get to practice the scripting language with your everyday interactive usage, which is one of the main reasons I'd eventually like to switch, even if I see that perhaps the most exciting use cases are wrangling JSON and YAML in scripts.

Re: Nushell.sh ls | where size > 10mb | sort-by modified

#176

Post by scubbo »

mtlmtlmtlmtl wrote: post #37
codetrotter wrote: post #27

Earlier quoted context omitted.

Historically we would discourage shell users from cat somefile.txt | whatever and instead tell them to use either whatever or, if the command accepts input file names as arguments then use those like whatever somefile.txt or whatever -i somefile.txt etc But perhaps in fish, “useless use of cat” is not so useless and would be recommended? (I mean aside from the fact that they seem to recommend their “open” command, an…

For some reason I never liked to do it the "right way". First of all it doesn't seem to actually matter. But most of all the cat way just aligns with my mental model more. Data flows left to right, if you catch my drift. It also makes it easier to add arguments to the end if re-running it.

Quite. I had occasion to share this[0] in another thread, and it's relevant here, too:

> When I offer a pipeline as a solution I expect it to be reusable. It is quite likely that a pipeline would be added at the end of or spliced into another pipeline. In that case having a file argument to grep screws up reusability, and quite possibly do so silently without an error message if the file argument exists. I. e. `grep foo xyz | grep bar xyz | wc` will give you how many lines in xyz contain bar while you are expecting the number of lines that contain both foo and bar. Having to change arguments to a command in a pipeline before using it is prone to errors. Add to it the possibility of silent failures and it becomes a particularly insidious practice.

[0] https://stackoverflow.com/a/16619430/1040915

Re: Nushell.sh ls | where size > 10mb | sort-by modified

#177

Post by ofchnofc »

amelius wrote: post #91
pxc wrote: post #48

Earlier quoted context omitted.

Many of these next-gen shells like Nushell are clearly (and sometimes explicitly) inspired equally by Fish and by PowerShell, and it shows. It's a brilliant combination!

I think the problem with this approach is that it breaks down at some point, and then your only option is to rewrite the entire thing in a real scripting language. I.e., there is no graceful scaling path.

[dead]

Re: Nushell.sh ls | where size > 10mb | sort-by modified

#178

Post by ripley12 »

kubb wrote: post #130

It would be neat to be able to add durations to dates. This would let me e.g. get all files that are newer than an hour: ls | where modified > time now - 1hr

This works in Nushell; it just needs parentheses:

ls | where modified > (date now) - 1hr

Re: Nushell.sh ls | where size > 10mb | sort-by modified

#179

Post by inciampati »

andrepd wrote: post #36
pxc wrote: post #16

Earlier quoted context omitted.

This reminds me of how Fish handles process substitution without requiring a special syntax. I love it! It may seem a bit odd or even cumbersome to experienced shell programmers, but in my experience with Fish, this kind of thing helps a lot with ease of learning.

It is much much better to have things be actual commands (which have a uniform syntax, and are `--help`able) rather than obscure sigils like $(#!@$). Fish is amazing!

Fish is amazing. And. It was missing critical features like subprocesses for so long (10 years?) that I had to keep passing it by. No subprocesses!

Re: Nushell.sh ls | where size > 10mb | sort-by modified

#180

Post by reddit_clone »

orf wrote: post #61
CraigJPerry wrote: post #57

Earlier quoted context omitted.

Depends what you’re optimising for. Are you optimising for readability - e.g. maybe you share shell history with team mates for example. Or are you optimising for getting your thoughts transcribed to the machine as quickly as possible. It’s usually this case for me. I tend to maintain a huge shell history so i really like the terse format for quickly filtering down my historical commands. Writing shell scripts might…

I also maintain a huge shell history, but in my experience fzf-ing through it becomes a lot harder when it’s terse and unreadable. But sure, there’s a tension between readability and brain-to-command throughput that’s always been there. The way you proposed is a bit too write-only for my taste, and the argument that you “had to learn it and now you’re muscle memory bound to it” is applicable to you only and does not…

I use a trick to improve this. I too have a 7 year Shell history with Fzf and love using it as my second brain.

I put #tags at the end of long, opaque, reusable commands so that I can FZF search it quicker.

Post reply on HN