[HN Gopher] Nushell.sh ls | where size > 10mb | sort-by modified
___________________________________________________________________
Nushell.sh ls | where size > 10mb | sort-by modified
Author : nailer
Score : 209 points
Date : 2023-03-12 18:24 UTC (4 hours ago)
(HTM) web link (www.nushell.sh)
(TXT) w3m dump (www.nushell.sh)
| jmole wrote:
| Read this as "Nutshell", which would have been a really cool name
| for a shell.
| david2ndaccount wrote:
| > Nu has great error messages
|
| The example is actually terrible though. It implies that changing
| the 10 to a string will make division a valid operation.
|
| It's also incredibly verbose.
| shortrounddev wrote:
| 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
| ripley12 wrote:
| I'm of the opinion that structured data is something PowerShell
| got 100% right; people tend to dislike PowerShell for other
| reasons (verbosity, startup time, Windows-first history).
| lionkor wrote:
| > I don't think I've ever met another dev who likes PowerShell
|
| I have, a few! But they are the kind of dev to never publish
| their work anywhere, not even little shell scripts. Secretive
| windows power users
| pmarreck wrote:
| I'd actually like the ability to do either raw bytes
| (traditional) or structured bytes (the NuShell/PowerShell idea)
| in an "opt-in" scenario. This would also allow a smoother
| transition/lack of needing to fully commit right off the bat.
| I've considered writing wrappers for standard utilities in
| Bash/Zsh that accept and output structured data in JSON (or
| maybe a denser serialization format that can easily convert to
| JSON?) instead of a raw byte stream that you could then just
| use regular old pipes with (a lot of `jq` would likely get
| called in between...) The "structured" versions of the
| utilities would have some namespacing convention such as a
| "struct_" prefix (or perhaps optionally, or aliased, for
| brevity, "s_") or (another naming idea I just had... oooh, I
| like this one) they would be boxed in brackets, so "[ls]" or
| "]ls[" would call "structured ls" (note that brackets without
| spaces around them are valid name characters)
|
| To handle the transition to/from structured data, an idea I had
| was to omit one of the brackets in these names, so for example
| "ls[" would emit structured data but accept (well, assuming
| "ls" was a command that took stdin) an unstructured bytestream,
| and something like "]cat" would take in structured data on
| stdin but emit raw data... "cat[" would take raw data and...
| interpret it as JSON? or something? and output that as
| structured data? I don't know, it has to be fleshed out, but
| this could work maybe!
|
| To get the JSON data back to a visual format like a table, we'd
| probably have to explicitly do what NuShell implicitly calls
| when you don't provide it (I forgot the name of it).
|
| anyway, I haven't even begun a POC of this idea, but it was one
| I had. Anyone else like this idea?
| CraigJPerry wrote:
| [zsh]$ ls -l *(Lm+10om)
|
| zsh supports extended globs, this says: -l give
| me a long listing "*(...)" of any file Lm+10
| who's size "L" in megabytes "m" is greater than 10 "om"
| ordered by modification ascending
| loeg wrote:
| Wouldn't you want to use 'ls -lt' (sort by time) (or possibly
| with '-r' if you really want oldest first)? (I.e., does 'om'
| sort the glob passed to 'ls', which it will then reorder, or
| does zsh do something magic with the 'ls' command?)
| CraigJPerry wrote:
| yeah if you were typing this case yourself you would use -lt
| but i figured it was worth showing that extended globs can be
| combined.
|
| This globbing functionality in zsh is separate from the ls
| command, so no ls magic here, but the ls builtin in zsh does
| have some useful extras in it all the same
| jiripospisil wrote:
| I had no idea Zsh could do that. I'm currently reading this
| article which explains a lot of this wizardry.
|
| https://thevaluable.dev/zsh-expansion-guide-example/
| orf wrote:
| Cool but that's as opaque and hard to understand as sacrificing
| a goat to order ls output.
|
| It's of course possible to do with existing shells, but it's
| impossible to argue that it's a _clear_
| CraigJPerry wrote:
| 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 be a good case for the longer
| form style although bourne-esque syntax is burned into my
| fingertips after all these years that long form is not going
| to be useful to me.
| orf wrote:
| 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 preclude a better way from existing.
| ape4 wrote:
| I like the trend of commands adding json output. Then you don't
| need to get a new shell just incrementally add other commands
| than can process json.
| pxc wrote:
| > other commands than can process json
|
| Happily, this includes import/conversion functions for new
| shells, so this plays nice with efforts like Nushell as well.
| dmix wrote:
| Plus having less cryptic version of jq is a big win considering
| how often we all work with JSON files these days. It should be
| a 'primitive' in shells like strings.
| HervalFreire wrote:
| [dead]
| reisse wrote:
| Few more decades of shell development and the people involved
| will maybe discover GUI with hotkeys. /s
|
| Seriously though, for me their front page fails to give a
| convicing example how it's better than existing shells for a
| typical shell workflows.
|
| Even the last one, which supposed to demonstrate better error
| messages, shows a cryptic error "change a or b to be the right
| types and try again". Perhaps type checking can help to say which
| argument is wrong and how to fix it? Now it's literally "one of
| your arguments is wrong, check man and try again".
| lloydatkinson wrote:
| What is the advantage over powershell?
| huhneverthot wrote:
| It's not batshit infuriating to use?
|
| Idk, I was an OG PowerShell, I'd take nushells approach every
| day of the week.
| bobleeswagger wrote:
| It's not Microsoft based?
| shortrounddev wrote:
| So there's no support from one of the largest tech companies
| in the world?
| alpaca128 wrote:
| I avoid MS products like the plague nowadays exactly
| because of their "support", including free overnight OS
| sabotage.
| bobleeswagger wrote:
| > one of the largest tech companies in the world
|
| Bigger isn't better my guy
| BrainBuzzer wrote:
| It's cross platform. Although of you're coming from
| powershell background, it is easier to learn.
| shortrounddev wrote:
| Powershell is also cross-platform
| [deleted]
| ghusto wrote:
| I'm sure there's a lot more once you get to more advanced stuff,
| but going through their System examples has me puzzled:
|
| > ls | where type == dir
|
| or in Bash:
|
| `ls -d`
|
| > ps | where cpu > 0 | sort-by cpu | reverse
|
| or in Bash:
|
| `htop` ?
|
| > ps | where name == Notepad2.exe > # find process, then ... > ps
| | where name == Notepad2.exe | get pid.0 | kill -9 $in
|
| or in Bash:
|
| `pkill Notepad2.exe`
|
| > Pipeline content to clipboard
|
| Or on MacOS:
|
| `anything | pbcopy`
|
| The first example is actually the only one that makes sense to
| me:
|
| > ls | where type == file
|
| Amazingly, there's no straightforward way to tell `ls` to output
| only files (that I know of):
|
| `ls -p | grep -v /`
|
| I don't mean to knock it, but I think it's better to learn the
| standard tools available everywhere than invest any time in tools
| that aim to lessen the learning curve.
| [deleted]
| boustrophedon wrote:
| `find . -type f -maxdepth 1`
| AdamJacobMuller wrote:
| > Amazingly, there's no straightforward way to tell `ls` to
| output only files (that I know of):
|
| `ls -l|grep -e^-`
|
| Unless you meant without pipes/grep in which case I think no,
| but, you're bumping up against the fact that `ls` is really
| more of a user-presentation tool than for scripting. Use `find
| . -type f` maybe with some `-maxdepth 1`
| jiggawatts wrote:
| He's giving simple examples everyone can quickly understand.
|
| When I show people the same advantage that PowerShell has over
| bash I pick harder problems where bash/gnu tools have no
| trivial answers. But then people get sour grapes and say "I
| don't need to do that kind of thing anyway." The reality of
| course is they _avoid_ those harder problems and solve them
| manually or with different tools (Python).
|
| Sorting is as good example, because while commands like 'ps'
| have _some_ built in sorting capability, it is limited and
| inconsistent with other tools. You can sort by some columns,
| but not others. Sorting by the same field is often a different
| option across different tools even if they manipulate the same
| objects, etc...
|
| If you would like a harder problem: kill every process on the
| machine run by the user "ash" that has used more than 1 hour of
| _total_ CPU time but only those of his processes that are in
| the top 5 in the entire system _by memory usage_.
|
| Hint: Don't kill anyone else's processes by accident even if
| their user name is "flash" or if their process name is "bash".
| Also don't confuse instantaneous %CPU with total CPU usage.
|
| Did I say total CPU? Oops, I meant total _kernel time_ used! My
| mistake. Update your a script, that should be a simple
| change... right?
| dr_kiszonka wrote:
| As with almost everything, Bash is easy once you learn how to
| use it ; )
|
| I think this tool is useful for people who need to use the
| terminal right now, without having to spend quite a bit of time
| learning, e.g., Bash. Your point about the portability of Bash
| is, of course, valid. It just that sometimes you need to get
| stuff done quickly without parsing, at times unfriendly,
| documentation of more mature tools.
| dvdkon wrote:
| I think you've partly proven that nushell is useful. `ls -d`
| doesn't list directories, it lists only the files given as
| arguments instead of their children. Also, htop is nothing like
| a scriptable and composable pipeline from ps, and there's no
| reason `pkill` couldn't co-exist with the equivalent of `kill
| $(ps | grep Notepad2 | grep -v grep)`.
|
| Dozens of specific commands and flags for specific usecases
| aren't always enough, and, dare I say it, counter to the UNIX
| philosophy.
| enoch2090 wrote:
| This is fun, but reading the commands[1] reminds me of learning a
| new language. There are just too of them, and they are all
| pipelined in a functional manner so I need to understand the I/O
| of them. In that case, why would one bother remembering all of
| those, when Xonsh or IPython does similar job to their data, only
| with a few more lines of (more familiar) code?
|
| [1]: https://www.nushell.sh/commands/
| cormacrelf wrote:
| I have written a bunch of nu and: no dot method syntax means
| you need to browse documentation for literally everything. So
| much worse than your average programming language, which takes
| the data type + you enter a dot = it suggests all the relevant
| methods. The Nu docs are better than they were a few years ago
| but as far as I can tell they keep changing command names,
| having subtle changes of behaviour for commands with the same
| name but apparently different implementations for different
| data types, having a crucial command listed under a weird name
| that takes an hour to find, etc etc. If I need to wrangle some
| JSON again I think I'll just use Python.
| tormeh wrote:
| My problem with alternative shells (anything not bash) is that I
| have to learn bash anyway, and if I want to use a scripting
| language that requires me to first install a runtime, drop into
| it, doesn't work on colleagues machines, etc. then there are many
| non-shell alternatives that are better. I'll learn nushell or
| whatever once a mainstream or somehow desirable distro ships with
| it as their default shell.
| xnyanta wrote:
| What's the advantage of this over PowerShell?
| operator-name wrote:
| - Better errors
|
| - Native support for JSON, etc (no more ConvertFrom-*
| ConvertTo-*)
|
| - Less verbose
|
| - Different visualisation
| Kwpolska wrote:
| PowerShell isn't _that_ verbose, compared to NuShell. The ls
| example would be (with standard PowerShell aliases):
| gci | where { $_.Length -gt (10 * 1024 * 1024) } | sort
| LastWriteTime
|
| -gt might seem weird, but it's better than overloading >.
|
| (Also, I like the fact that PowerShell is built into Windows
| and has a large corporation behind it.)
| qorrect wrote:
| Sorry but that looks terrible.
| jrumbut wrote:
| I don't mind the looks but I find it hard to debug and
| have a poor instinct for "does this need a curly bracket
| or a parens?" That's my real issue with PowerShell, I
| find it very hard to predict what will work unless I know
| exactly what the rule is.
|
| Shell has similar issues but I've put 20 years into it so
| the knowledge is there. Every time the PowerShell people
| describe PowerShell I think "that sounds awesome" but the
| ergonomics don't work for me.
| justeleblanc wrote:
| Parentheses are for grouping. Curly brackets are for
| creating a new script block. If you would have wanted to
| write "function foo() {}" in another language, go for
| curly brackets. It's really not that complex.
| Arnavion wrote:
| Blocks always use braces. Expressions use parentheses for
| grouping sub-expressions. It's the same as many C-like
| languages. I can't imagine any situation where you would
| be confused which one you need to use.
| marcosdumay wrote:
| > I can't imagine any situation where you would be
| confused which one you need to use.
|
| Why is that test returning a boolean on the GP a block?
| Arnavion wrote:
| Because it's an arbitrary piece of code that needs to be
| re-evaluated for every input item, like an inline
| function / lambda in other languages, not an expression
| that is evaluated once when the commandline is
| instantiated.
| jrumbut wrote:
| Blocks always use braces, but sometimes you are passing
| parameters and other times you are passing a block.
|
| If I spent all day as a PowerShell dev I'm sure I would
| know it, but for something I reach for once or twice a
| year intuitiveness is a feature I would like to have.
| Kwpolska wrote:
| What about it looks terrible? The braces are necessary,
| because this is a lambda.
| vips7L wrote:
| You don't need the lambda. Where-Object can just take the
| Length property.
| doodlesdev wrote:
| I'd say that $_ is really weird and looks horrible. Also
| having to do (10 * 1024 * 1024) instead of just writing
| 10MB is a downgrade even compared to POSIX-compliant sh.
| In my other comment I've added a few examples in sh, zsh,
| and a better PowerShell example: gci | ?
| Length -gt 10MB | sort LastWriteTime
| [deleted]
| doodlesdev wrote:
| The fact PowerShell has this masochistic tendency to have
| commands that start with capital case already makes it
| outside of the realm of consideration for me. It's absolute
| nonsense. Also I have to say your example is extremely
| confusing and would probably take quite a bit of time to
| write IRL. For reference, the equivalent in sh would be:
| find . -maxdepth 1 -type f -size +10M -exec ls -lt {} +
|
| Or a very terse example: du -s -h * |
| sort -r -h | sed 10q
|
| The thing is that if you're already used to POSIX-compliant
| shells then this is simply natural to write. Nushell has a
| different proposition of making it closer to natural
| language, which makes the learning curve much better.
| PowerShell just makes it different, but not really that
| much better.
|
| Also this is somewhat tangential, but I hate that
| PowerShell 5 and 7 are completely different things, and
| that PowerShell 5 is still the default even in Windows 11.
|
| Oh yeah, and just for lols this is the same thing in zsh:
| ls -lt *(.L+10240k)
|
| By the way, I should note that it's possible to make the
| PowerShell example much simpler like the following:
| gci | ? Length -gt 10MB | sort LastWriteTime
|
| The thing that really gets me here is the need to know
| aliases to keep it short, if you were to do it without the
| aliases it would look like this: Get-
| ChildItem | Where-Object { $_.Length -gt 10MB } | Sort-
| Object LastWriteTime
|
| Also, again, case-sensitive commands make me mad.
| vips7L wrote:
| PowerShell isn't case sensitive. Personally I prefer
| `where` over `?` though.
| shortrounddev wrote:
| ls is an alias for Get-ChildItem in Powershell as well,
| btw
| Arnavion wrote:
| Only on Windows. On Linux it's the original `ls`. Same
| for `cat` and many other commands. That's why using `gci`
| / `gc` is safer if you want your script to work
| everywhere.
|
| https://learn.microsoft.com/en-
| us/powershell/scripting/whats...
| justeleblanc wrote:
| Commands aren't case sensitive. Just try it! Tab
| completion even works if you start the command lowercase.
|
| As for needing to know aliases... Did the knowledge that
| 'du' stands for 'disk usage' exist in your brain at
| birth, or did you have to learn it somehow? That
| criticism is nonsense.
|
| At least with powershell, commands have a canonical,
| explicit name with standard verbs and nouns; and a short
| alias that's equivalent to the initial command in every
| way. What I also like is that parameters have aliases
| too: you can write - WhatIf or -wi and it'll work the
| same. And everything is documented.
| kitkat_new wrote:
| tbh, I have used way more bash than ps in my life so far,
| and the following command is the only one, I understand
| without googling anything:
|
| Get-ChildItem | Where-Object { $_.Length -gt 10MB } |
| Sort-Object LastWriteTime `
| tosihakkeri wrote:
| This is written in Rust
|
| /s
| avgcorrection wrote:
| No, that's not mentioned as an advantage on the website.
| k0k0r0 wrote:
| I assume the parent comment did not make fun of nushell
| advertizing this, but instead about the rust community
| advertizing itself all the time.
| huimang wrote:
| To be honest, they have good reason. Being written in a
| strongly typed, memory-safe language is a huge advantage.
| Obviously it's not the primary thing to look out for, but
| I do prefer tools that are written in it.
| zozbot234 wrote:
| > Being written in a strongly typed, memory-safe language
| is a huge advantage.
|
| Great point, C# is a strongly typed and memory-safe
| language if you don't use unsafe. So this really is a
| huge advantage for PowerShell.
| vips7L wrote:
| There are plenty of strongly typed memory safe languages.
| In fact I think those are the majority of popular
| languages.
| marcosdumay wrote:
| Yet, almost all the basic tools in a Unix system are
| written in C.
| HervalFreire wrote:
| [dead]
| triyambakam wrote:
| I'm not really sure which other popular languages would
| be considered memory safe AND strongly typed. I know of
| both C and C++ which I wouldn't consider memory safe. And
| I know of Javascript, which is not strongly typed... so
| which do you mean?
| vips7L wrote:
| Java, Scala, Kotlin, C#, D, Go, and TypeScript to name a
| few.
| ripley12 wrote:
| Recycling my comment from last time this came up. Some reasons
| I prefer Nushell over PowerShell:
|
| - less verbose syntax
|
| - better cross-platform support (PowerShell is technically
| cross-platform, but it has some baggage from its Windows-first
| history)
|
| - way faster to start up
|
| I'm biased (I'm a member of the Nushell core team), but those
| are all things that drew me to start contributing to Nushell.
|
| On the other hand, Nushell is certainly less mature+stable than
| PowerShell. And if Windows administration is your main use
| case, PowerShell can't really be beat.
| mbStavola wrote:
| I have nothing but positive things to say about nushell, but I do
| wish the describe command took a positional argument rather than
| just being piped into. I was trying to write a pipeline that
| could give me all the versions from a Cargo.toml and "flatten"
| any records, but got stuck trying to use describe. Ex:
|
| open Cargo.toml | get dependencies | transpose | rename dep
| version | each { |row| let version = $row.version; if (describe
| $version) =~ "record" { $version.version } else { $version } }
| evntdrvn wrote:
| Have you tried opening up a feature suggestion? The maintainers
| are very receptive/helpful from my experiences.
| msmart wrote:
| I would use
|
| open Cargo.toml | get dependencies | transpose | rename dep
| version | each { |row| if (($row.version | get -i version |
| default "" ) != "") { $row.version.version } else {
| $row.version } }
|
| not sure whether that's the best way.
| ryukoposting wrote:
| Seems like a less-asinine take on the ideas underlying
| PowerShell. Neat!
| lordofgibbons wrote:
| This looks extremely interesting! Is anyone using it as a daily
| driver on Linux? How has your experience been?
| huhneverthot wrote:
| Yes, daily driving it (it's my default shell in zellij), and
| have ported my use-every-5-mins scripts to it.
|
| It's VERY refreshing, but I still have issues with it not
| short-circuiting when an error is thrown in a loop... Which I
| suspect will get fixed in time...
| BrainBuzzer wrote:
| I have been using this on my Linux and windows machine as a
| daily driver. It's cross platform approach to handling
| commands, and overall usability is what made me switch to this
| completely. It takes a little while to get used to, especially
| when coming from bash, but if you know powershell already, I'd
| say just give it a go.
| qorrect wrote:
| I second this question. I was using FISH for quite a while and
| really liking it, but there was always something that it was
| incompatible with and had to eventually give it up.
| aldanor wrote:
| I gave up on fish many years ago because of various
| incompabitilities (e.g. syntax like `FOO=bar some-cmd` or
| `env FOO=bar some-cmd` etc), but to be fair, they have
| managed to patch lots/most of those.
|
| Returned back (from zsh) to fish this year and am super
| happy. Still the best built-in completion / history auto-
| suggest that I've seen in any shell so far, and super-fast at
| that.
|
| Most importantly, barely any config needed (no needs for oh-
| my-zsh, prezto and all of those).
| robertlagrant wrote:
| I read that several times thinking it was Nutshell. And now I
| wish it were.
| nailer wrote:
| This has been on HN previously but it's a couple of years later
| and pleased to see it's still a very active project
| https://www.nushell.sh/blog/ with good documentation:
| https://www.nushell.sh/cookbook/
| derhuerst wrote:
| some past HN discussions: -
| https://news.ycombinator.com/item?id=20783006 -
| https://news.ycombinator.com/item?id=27525031 -
| https://news.ycombinator.com/item?id=33419944
| steveklabnik wrote:
| I've been using nu as my main shell for a few years now. Very
| happy with it.
| akira2501 wrote:
| So, '>' isn't for redirection anymore. How does one do that?
| open foo.txt | append "world"| save --raw foo.txt
|
| Oh.
| pxc wrote:
| 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.
| andrepd wrote:
| 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!
| pxc wrote:
| 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!
| amelius wrote:
| 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.
| stingraycharles wrote:
| 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?
| ilyt wrote:
| Should be doing that anyway, bash is terrible for actual
| programs.
| pxc wrote:
| I suppose I'm more optimistic. From my point of view,
| structures pipelines and some of the goodies that come
| with it (like better error handling), can make a shell
| language into a perfectly capable scripting language. I
| think the big weakness for these new shells is in the
| small sizes of their library ecosystems. But PowerShell
| shows what a language of this kind can do with a sizeable
| ecosystem and some OS integration.
| jntrnr wrote:
| Or: open foo.txt out> bar.txt
| codetrotter wrote:
| Historically we would discourage shell users from
| cat somefile.txt | whatever
|
| and instead tell them to use either whatever
| < somefile.txt
|
| 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, and so they probably prefer their own "open"
| over "cat".)
| mtlmtlmtlmtl wrote:
| 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.
| tomsmeding wrote:
| While I get your point...
|
| > It also makes it easier to add arguments to the end if
| re-running it.
|
| I'd like to point out that a redirection doesn't have to be
| the last thing in a command. E.g. the common 'echo >&2
| "some message"' works fine.
| alas44 wrote:
| I share the same opinion, I was made fun of with the
| "useless use of cat award" but find it so convienent to cat
| | grep then cat | grep | awk | wc then whatever with data
| flowing left to right and modifying the command sequence as
| I explore the file content.
| Arnavion wrote:
| >But most of all the cat way just aligns with my mental
| model more. Data flows left to right, if you catch my
| drift.
|
| Using `<` doesn't change that model. You can write `<
| somefile.txt whatever`. I always write my commandlines as
| `<in_file cmd1 | cmd2 | cmd3 >out_file`
|
| (Though annoyingly this doesn't work for feeding input to
| while loops. `< <(echo a; echo b; echo c;) while read -r
| foo; do echo "$foo"; done` is invalid syntax; it needs to
| be `while read -r foo; do echo "$foo"; done < <(echo a;
| echo b; echo c;)`)
| ilyt wrote:
| > Using `<` doesn't change that model. You can write `<
| somefile.txt whatever`.
|
| If you showed that without context it would look like
| some prefix/lispy notation so no, you are just showing
| how bad it is
| kccqzy wrote:
| 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).
| codetrotter wrote:
| Yeah but you get the same from random-
| app < ./myfile.txt
| marcosdumay wrote:
| > Historically we would discourage shell users from...
|
| For no good reason at all.
|
| It's not less confusing, and when shell programmers start
| talking about how wasteful it is to fork another process,
| it's because all the good explanations were already refuted.
|
| Also, it's worth pointing that this style was never
| unanimous. There is a very vocal minority that pushes for it,
| and a wide non-vocal majority that says basically "whatever,
| it's not like there's any difference" if you go and ask the
| question.
| version_five wrote:
| 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:
| $ < file util1 | util2 | util3 | ...
|
| 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
| mort96 wrote:
| 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.
| codetrotter wrote:
| 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
| mort96 wrote:
| 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'".
| asda22sdasd wrote:
| Sounds like you describe a interactive shell session, not
| stuff that happens in that script that was written for a
| specific purpose.
| e12e wrote:
| Hm. Why not re-use "tee"?
|
| https://www.man7.org/linux/man-pages/man1/tee.1.html
| pxc wrote:
| `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.
| felixgallo wrote:
| du -s * | sort -n -r | sed 10q
| e12e wrote:
| "sed 10q" is equivalent to "head"?
| theossuary wrote:
| Okay, but now show me the size of the file in a human readible
| format next to the name.
| [deleted]
| [deleted]
| benhoyt wrote:
| You can use the "-h" (human-readable) options to du and sort
| to do this: $ du -sh * | sort -rh 20M
| dist 6.9M pebble 1.5M internal 308K cmd
| ...
| [deleted]
| matja wrote:
| add: | numfmt --to=iec
| felixgallo wrote:
| it's already in a human readable format next to the name.
| PeterWhittaker wrote:
| du -s -h * | sort -r -h
| zzo38computer wrote:
| I have been given a link to this when I was describing my ideas
| of an operating system design, since some of the ideas are
| similar. However, many ideas are different, since the operating
| system is in many ways fundamentally different from Windows and
| from POSIX. Some of these differences may allow such a similar
| idea to even work better in some ways, possibly.
| jedisct1 wrote:
| 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 Vim/Emacs/VSCode or a trivial Python/Ruby
| script.
| HervalFreire wrote:
| 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.
| sp33der89 wrote:
| Fish is that shell for me. I tried nushell and zsh. zsh
| required a bunch of setup and nushell was too young. Whereas
| fish has really great defaults and enough of support to just
| go and have fun.
| ilyt wrote:
| > What if someone starts from a clean slate. Which shell is
| better?
|
| Then they learn the better and end up having to learn bash
| anyway coz that's what runs on remote machines.
|
| There is also not that much to be gained. Common easy tasks
| might be easier to learn but just few percent faster in the
| end. Harder ones are faster by one-off script in "real"
| programming language most of the time. Harder repeatable one
| should never be written in shell or shell-like language
| because it is just a terrible one to write any real programs.
|
| Also if you _really_ spend that much time gnobling in shell
| you 'd be FAR better off investing time into learning
| configuration management tools.
| typon wrote:
| 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.
| kubb wrote:
| 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
| smallerfish wrote:
| What's the story with not having a deb / flatpak / appimage or
| snap distribution? Just lack of resources to help package?
| ripley12 wrote:
| Don't think we've had any requests for those, but we'd welcome
| contributions if someone wants to make it happen.
|
| For now, Homebrew works if you want a cross-distro way to
| install Nu on x64 Linux.
| guilhas wrote:
| I find this project interesting
|
| But doesn't it look like too monolithic? That will have problems
| with maintenance and scaling? And features that overlap with many
| already existing cli tools?
| ripley12 wrote:
| I think Nu generally plays nicely with other CLI tools and data
| sources. For example if you've got an external executable that
| emits JSON, all it takes is `from json` to convert that output
| to a Nushell table.
| huhneverthot wrote:
| It's so wildly awesome to deal with data natively in nushell
| than donhacky shit with jq and strings... In bash. No thanks.
| joveian wrote:
| That inspired me to give it a quick try, however the
| assumption that white on bright white is a readable color
| conflicts with the need to make them the same color for other
| software that I use (which only use eight colors and I want
| white to be white). I'm guessing this might be configurable
| for anyone sufficiently interested.
| [deleted]
___________________________________________________________________
(page generated 2023-03-12 23:00 UTC)