Live data from Hacker News

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

nushell.sh

101–110 of 215 posts

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

#101

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…

What if someone starts from a clean slate. Which shell is better?

That is the question. Old habits hold us back from progress in usability. Eventually if one system is better it should completely replace the old system. But only if it's better. What one power user deems as "useful" according to his own usage patterns shouldn't be a metric for measurement.

I haven't played with nushell yet, but it actually seems more powerful then python for shell tasks. All the data structures are catered towards easy visualization and parsing parameters related to a shell. Python does not have such convenience.

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

#102

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…

Unfortunately I felt the same way. I'm probably their prototypical target audience (neovim user, I stay in the terminal 99% of the time) and I couldnt justify switching over to nushell full time. I wish they didn't change the syntax too much - there's still tons of scripts and commands that work on zsh or bash and are used in normal work flows.

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

#103
post #96

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…

The use of cat is not useless. Having a "read this file" command be the source of the pipeline makes a lot of sense. It makes it seamless to replace the cat with a pv if you want progress, zcat if you're reading a gzipped file, curl if you want to use a URL, etc.

Fair point.

But how often do you make those kinds of changes in any of your scripts and not have to change anything? For me, exactly 0 times

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

#104

So, '>' isn't for redirection anymore. How does one do that? open foo.txt | append "world"| save --raw foo.txt Oh.

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…

I'm also a big fan of doing it the wrong way. (While I understand there is no practical difference) I find it more natural, because it's symmetrical (or parallel:

  $ 
The first util is the originator of the data pipeline, and it plus the file are the first command

  $ cat file | util1 | ... 
Each utility is it's own thing, being fed a data stream that came from cat. I know it's just personal preference but it feels neater

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

#105

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.

Besides it's also a fail-safe way to make sure the program doesn't modify the original file.

    random-app ./myfile.txt 
The app opens the file on its own. It could decide to write to it.

    cat ./myfile.txt | random-app
The app receives chunks of the file from a pipe. It doesn't know where the original file is.

This is especially useful if you aren't sure the program will by default modify the file (such as formatters).

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

#107
post #96

Earlier quoted context omitted.

The use of cat is not useless. Having a "read this file" command be the source of the pipeline makes a lot of sense. It makes it seamless to replace the cat with a pv if you want progress, zcat if you're reading a gzipped file, curl if you want to use a URL, etc.

Fair point. But how often do you make those kinds of changes in any of your scripts and not have to change anything? For me, exactly 0 times

Quite frequently? "Oh this operation turned out to take a while, I'll use pv instead of cat", or "oh what I grepped for wasn't in the current log, it's probably in the previous log that's gzipped, I'll replace 'cat current.log' with 'zcat previous.log'".
Post reply on HN