Live data from Hacker News

GitHub – nushell/nushell: A new type of shell

github.com

241–250 of 411 posts

Re: GitHub – nushell/nushell: A new type of shell

#241
post #54

Earlier quoted context omitted.

I’m sorry to say this but this is a very uninformed comment with way too many biases without any backing. > I.e. it wasn't created from the need, like someone at Microsoft wanted to automate his work and created PS to solve his problem Interestingly enough, it is used for automating Windows configuration. Re last paragraph: UNIX commands are random letters that are like that due to historical reasons — if you don’t k…

Yes, I haven't used PowerShell. And I agree that my comment is uninformed. It's just that I feel uncomfortable even looking at the PS syntax. Maybe it's idiosyncratic. Maybe I've spent too many years in Unix shell.

Idiomatic Powershell is definitely verbose, but you get used to it (and you can disregard if you want). The verbosity can be used to make it more human readable, if done right. I use Powershell on a daily basis - the biggest thing that people have noted is passing objects, instead of text. At first it was weird, but now I find it really helpful. It makes it very easy to tie components together, without having to slice and dice text.

Another great feature is named parameter support. It's so much easier to deal with parameters than with other languages I've used.

Re: GitHub – nushell/nushell: A new type of shell

#242
post #234
post #227

Earlier quoted context omitted.

That's not entirely weird to me. For the longest time bash was in various states of disrepair on different Unixes. I could make it segfault pretty easily. I wrote scripts that had to run across Linux, BSD, HP-UX, Solaris, and AIX at the time. So we relied on a ksh88 implementation on each. Whether it was AT&T, mksh, or pdksh, it was fine. Couldn't rely on 93isms, but basically anything POSIX was cool. I used ksh93 in…

Shellcheck is nowadays a must for writing decent shell scripts. it is like a centralized knowledge base of all those brilliant minds that did the sanity checking for you in the old days :)

It boggles my mind that people use a language where

x = 0 doesn't work and x=$y is a security flaw

Re: GitHub – nushell/nushell: A new type of shell

#243

I wonder if this could be accomplished in a more general way with a fourth standard file descriptor for structured data. stdjson basically.

What's wrong with plain old stdout? Lots of people do this with JSON (jq, etc.) and CSV or TSV (csvkit, etc.), XML/HTML, and more.

That's how I generate much of the https://www.oilshell.org/ site. It's just a tree of files and various shell commands, some of which I wrote myself.

I do think we need something better than CSV and TSV for tabular data though. They both have serious flaws (not being able to represent values with tabs, etc.!)

Re: GitHub – nushell/nushell: A new type of shell

#244

I wonder if the pipelining could be added to a regular shell to get its advantages - the cost for me from moving from Bash is too high. Basically a "cols" command on steroids - making that have some kind of context aware column names (I'm not sure how) and then support expressions would make it work in any shell.

That's basically what Oil's approach is. Oil is POSIX and bash compatible, but it also has Python-like data structures (recursive dicts, lists). And there's also room to add select/filter/sort. We need help :)

https://github.com/oilshell/oil/wiki/Structured-Data-in-Oil

Re: GitHub – nushell/nushell: A new type of shell

#247

It looks very interesting, but the first thing I noticed as a macOS user, is the shell has a built-in command "open" which I expect will conflict with the standard macOS command "open" and I haven't found any docs that describe how to deal with this.

This is true of shell built-ins for eg. test too.

The solution is to use the full path if you want to use the program, not the shell built-in.

In this case, "/usr/bin/open" not "open" will get you the macOS utility. If you get sick of doing that, create a shell alias.

Re: GitHub – nushell/nushell: A new type of shell

#248
post #236

Earlier quoted context omitted.

Disclaimer: I use PowerShell on Windows, I've never tried it on Linux, but I don't see why its advantages wouldn't transfer. That being said, I think it's main advantages are: - Typed object streams, which gives you stuff like autocomplete, IDE support, and generally there's no need to muck about with sed/awk/xargs - Very fast, it's absolutely fine to read a file line by line, and parse it in a script, whereas doing…

Nice summary. It leaves me wonder, though: is the philosophy the same as in Unix world? as in, little independent tools that do one and just one thing. Would those tools also need to be modified to add compatibility with the same typing system that is used by the shell? Or it follows the opposite mentality and the sell comes with batteries included? I'm thinking of some arbitrary example, like downloading a JSON and…

In powershell you would use built ins.

To download json over rest you would use Invoke-RestMethod or irm.

To convert json to objects you would use ConvertFrom-Json.

To select properties from objects you would use Select-Object or select.

Here is a concrete example that I wrote for the rustlings install script: https://github.com/rust-lang/rustlings/blob/main/install.ps1...

Note that I used Invoke-WebRequest instead of irm here.

Re: GitHub – nushell/nushell: A new type of shell

#249
post #107

Thinking this is so cool! I was wondering if seriously buying into an alternate shell like this would be worth it in the long run. Would really love to read from people who use(d) an alternative shell, both success and failure stories. I cannot shake from my head the idea that buying into a non-standard shell will only work for personal projects in one's own workstation, but it won't fly too far for company work beca…

I tried and returned to Bash. There is something about using defaults.

Re: GitHub – nushell/nushell: A new type of shell

#250
post #236

Earlier quoted context omitted.

Disclaimer: I use PowerShell on Windows, I've never tried it on Linux, but I don't see why its advantages wouldn't transfer. That being said, I think it's main advantages are: - Typed object streams, which gives you stuff like autocomplete, IDE support, and generally there's no need to muck about with sed/awk/xargs - Very fast, it's absolutely fine to read a file line by line, and parse it in a script, whereas doing…

Nice summary. It leaves me wonder, though: is the philosophy the same as in Unix world? as in, little independent tools that do one and just one thing. Would those tools also need to be modified to add compatibility with the same typing system that is used by the shell? Or it follows the opposite mentality and the sell comes with batteries included? I'm thinking of some arbitrary example, like downloading a JSON and…

Powershell commands (called "commandlets" or "cmdlets") are little .net (or .net core) programs/methods which accept and return either objects or arrays of objects, rather than plain text.

powershell offers cmdlets which let you sort and filter these result objects based on object property values rather than sorting on plain text values.

Obviously when printing to stdout or stderr, THAT bit is plain text, but until that very last step of displaying in the terminal, powershell results are objects.

So, that gives you a form of type safety, which isn't strictly possible in text-only shells. Powershell uses reflection to inspect the objects since the exact type of a response may have never been seen before. You can write your own cmdlets which return your own types and you can modify types returned by cmdlets using operators like 'select'. So, it's type-safe but not like everyone is used to. Powershell cmdlets always return objects (or errors, I guess), but the structure of those objects isn't always known until runtime. You can still use those never-before-seen types with the standard operators like sort and select, too.

Powershell also offers output conversion cmdlets which let you output to CSV or a textual table or a list, which is helpful when the next step in your pipe chain is a tool that expects textual input or a csv file. One can also write their own output formatters, of course.

In those ways, powershell and nushell appear to have the same goals. I haven't looked at nushell any more closely than it would take to notice this, so there may be other similarities I haven't noticed, yet. I'm sure there are many differences that I haven't noticed yet, as well.

Post reply on HN