Did all this stuff need to be a shell? I mean it replaces ls, a command that lists items in the current directory (in my experience, sorted by name by default), with a command that needs to be piped into sort-by name, which means you need to know “name” is a field, making ls equally or more complicated than piping it into sort. And instead of a series of rows you get an unnecessary ascii table. A lot of what this shell seems to do with where, sort-by, get and the like are simply achieved with awk. Can someone explain this project to me? I really must not get what it’s trying to achieve, what is being done that a moreutils-style package couldn’t do?
The idea is precisely to not have to use languages like AWK to do stuff that requires structure. Traditional Unix shells only work with plain text, however some shells like PowerShell work with objects instead of plain text (plain text is just a special type of object), which are more composable on its own.
I totally get structure, which is achieved by tools like relational pipes, there is an actual structure transferred from process to process; this appears to be as simple as column names
But what’s the difference between a “nested table” with 23 rows and a regular file with 23 lines? UNIX had relational database style operators like join over 40 years ago. They are still in coreutils today. I have literally no idea what this achieves
But what’s the difference between a “nested table” with 23 rows and a regular file with 23 lines?
The nested table is an explicit data structure with fields of structured data types, including other tables, and your regular file with 23 lines is a flat ad-hoc blob of bytes that isn’t going to safely, cleanly, or sensibly encode something as trivial as a filename.
You can’t safely or easily extract directory names from du:
-% du
1033 foo bar
lolwtf
And doing anything with these looks like, erm, “fun”:
-% ls
foo\ bar\nlol\001wtf\n/
-% gls
'foo bar'$'\n''lol'$'\001''wtf'$'\n'
But this works just fine:
> du | get path | rm --recursive $it
deleted /home/freaky/code/nushell/x/foo bar
lolwtf
And so does this:
> ls | get name | rm --recursive $it
deleted /home/freaky/code/nushell/x/foo bar
lolwtf
I think there is still a decent amount work to do here yet. For example, it doesn’t seem possible to effectively cd from the results of a pipeline, or if it is, I haven’t managed to figure that out. It’s probably possible via a plug-in.
Not sure if linking to a top-level of Github repos is the best way to let someone know about something…
Here’s some other discussions about Nushell:
Huh. I’m not sure how that happened. I intended to link to the main site here: https://www.nushell.sh/
Maybe a moderator can update the link?
…so how do I write a function? :D
They’re still working on scripting support. Right now, nu only supports interactive use and simple statements.
Did all this stuff need to be a shell? I mean it replaces
ls, a command that lists items in the current directory (in my experience, sorted by name by default), with a command that needs to be piped intosort-by name, which means you need to know “name” is a field, makinglsequally or more complicated than piping it intosort. And instead of a series of rows you get an unnecessary ascii table. A lot of what this shell seems to do withwhere,sort-by,getand the like are simply achieved withawk. Can someone explain this project to me? I really must not get what it’s trying to achieve, what is being done that amoreutils-style package couldn’t do?The idea is precisely to not have to use languages like AWK to do stuff that requires structure. Traditional Unix shells only work with plain text, however some shells like PowerShell work with objects instead of plain text (plain text is just a special type of object), which are more composable on its own.
I totally get structure, which is achieved by tools like relational pipes, there is an actual structure transferred from process to process; this appears to be as simple as column names
It’s certainly not limited to column names - it’s a stream of nestable, typed values. Take
dufor instance:pathis of typePathBuf, not just a string,apparentandphysicalare of typeBytes, anddirectoriesis a nested table with 23 rows of its own:But what’s the difference between a “nested table” with 23 rows and a regular file with 23 lines? UNIX had relational database style operators like
joinover 40 years ago. They are still incoreutilstoday. I have literally no idea what this achievesAbility to do something vs ability to do something in an easy and consistent way
The nested table is an explicit data structure with fields of structured data types, including other tables, and your regular file with 23 lines is a flat ad-hoc blob of bytes that isn’t going to safely, cleanly, or sensibly encode something as trivial as a filename.
You can’t safely or easily extract directory names from
du:And doing anything with these looks like, erm, “fun”:
But this works just fine:
And so does this:
I think there is still a decent amount work to do here yet. For example, it doesn’t seem possible to effectively cd from the results of a pipeline, or if it is, I haven’t managed to figure that out. It’s probably possible via a plug-in.