It feels a lot more like programming and actually gives you useful suggestions right inside the terminal!
On Linux the auto completion behavior is luckily less obnoxious than on Windows and it doesn't have the multi second startup delay either.
It's powerful but the syntax and semantics are maddening.
It's going to be entrenched in the Windows world for the next 20 years and prevent anything better from coming along.
Your array logic returned just one element in this folder? Why, we’re unwrapping that!
A Unix shell like bash or Oil is natural on Unix, where the OS uses text files. And in distributed systems where data is JSON, YAML, XML, protobuf, msgpack, etc. not objects.
So basically shell is a "situated" language, and the easy of accomplishing any given task depends a lot on the environment.
Windows is more tightly coupled and trying to provide something nice for you. Unix is messier but doesn't limit you, and it's what basically all big systems are made of these days. A major strength of shell is to glue things together that nobody thought should be glued together.
---
Good example here from Paul Bucheit: http://www.oilshell.org/blog/2020/01/simplest-explanation.ht...
http://paulbuchheit.blogspot.com/2009/01/communicating-with-...
However, we needed a way for Gmail to make money, and Sanjeev Singh kept talking about using relevant ads, even though it was obviously a "bad idea". I remained skeptical, but thought that it might be a fun experiment, so I connected to that ads database (I assure you, random engineers can no longer do this!), copied out all of the ads+keywords, and did a little bit of sorting and filtering with some UNIX SHELL COMMANDS
I then hacked up the "adult content" classifier that Matt Cutts and I had written for safe-search, linked that into the Gmail prototype, and then loaded the ads data into the classifier. My change to the classifier (which completely broke its original functionality, but this was a separate code branch) changed it from classifying pages as "adult", to classifying them according to which ad was most relevant. The resulting ad was then displayed in a little box on our Gmail prototype ui. The code was rather ugly and hackish, but more importantly, it only took a few hours to write!
----
Also, use whatever's best for you, but Unix people tend to hate PowerShell:
https://medium.com/@octskyward/the-woes-of-powershell-8737e5...
PowerShell feels like it was built by people who had heard about command lines a long time ago and tried to recreate one based on stories passed down through generations of their ancestors
The fact that they cargo-culted operators like -eq, -le, -lt, while not maintaining compatibility is just silly to me. In Oil it's "x == y" for string equality.
JavaScript Object Notation doesn't map well to objects?
We should try to pass around just state and keep objects strictly for code.
So the entire shell script is confined to the .NET VM?
In that case, I would hesitate to even call it a shell in the traditional sense.
Shell has a kind of code <-> data <-> code <-> data architecture, i.e. programs in different languages processing standard language-independent data formats (lines of text, JSON, HTML, QSN, etc.)
It's more like functional programming, where functions stand alone. (And note Oil is in a very OO style, because it deals with significant program state, so I'm not against objects. Right tool for the right job.)
-----
Other questions:
What if I want to pass some data to R and plot it? Or throw away some outliers with a little formula? I now have to figure out how to serialize those objects. Or do I have to write an R interpreter for the .NET VM? :)
What about splitting the pipeline over two different machines? I can do "ssh user@host find / -type f" trivially in shell. And I do this in practice, e.g. in Oil's continuous build: http://travis-ci.oilshell.org/jobs/
"Distributed objects" have proven to be a bad idea. "Real" (large scale, deployed) distributed systems are architected more like Unix than Windows.
The point of shell is to integrate disparate tools, so if there are some privileged tools in the .NET VM, and then some other tools that require a lot of work to get at, then that misses the point IMO.
> Shell has a kind of code <-> data <-> code <-> data architecture, i.e. programs in different languages processing standard language-independent data formats (lines of text, JSON, HTML, QSN, etc.)
Powershell natively understands these with builtins. You can convert from and to json, xml, html, csv, and excel.
> What if I want to pass some data to R and plot it?
Just pipe it to your R program like you would any other shell.
One of PowerShell's nifty tricks includes being able to walk a SQL DB like its a file system, see https://docs.microsoft.com/en-us/sql/powershell/navigate-sql...
PowerShell is insanely flexible.
When I want to program a script, I can use a scripting programming language like Python with its object oriented nature.
When I want to interactively command my computer I can use a shell like bash or zsh.
Do one thing and do it well.
That's how we got in today's mess.
Do the things people want in a coherent, cohesive, well thought out way - don't combine N independent programs that can barely took to each other with stringly typing and ad-hoc parsing...
But I would be OK with
(a) shell programs that talk to each other through pipes with something structured -- e.g. depending on the program with something like a pandas dataframe(binary) a parsable tree (e.g. json-like) or csv output and input -- as opposed to random text people try to parse with cut -f, regexes and so on.
(b) shell programs that share the same flags for the same things (not e.g. -o/--output for output in one program and -w/--write-file in another) and only specialize in the behavior they need...
and several other things besides...
Someone on here previously showed a trick to get some speedups, but it is still slow.