Live data from Hacker News

Four features that justify a new Unix shell

oilshell.org

21–30 of 185 posts

Re: Four features that justify a new Unix shell

#21
post #11

Are there any transpile to bash languages? I like the idea of a language that allows for a better experience in writing shell scripts -- and produces shell scripts with fewer bugs on the output side. But i wonder if a transpile approach wouldn't be better in the long run

(author here) Yeah I've been asked that before, and there are some things you can fix with a transpiler, but somethings you can't. That's why the tagline to Oil is now "our upgrade path from bash to a better language AND RUNTIME". The shell runtime needs to be fixed too, e.g. the error handling mentioned in the blog post and that I follow up on here: https://news.ycombinator.com/item?id=24872986 You might be able to…

So is the normal usage path to start using osh for interactive use and then use osh in a bash compatible mode to write scripts that are less buggy but can still be run on bash?

Or is it more common to write scripts that tend to then require the osh runtime exist in whatever context they are deployed to?

Re: Four features that justify a new Unix shell

#23
post #12

Two ergonomic issues in POSIX/bash not mentioned that I’d like to see a new shell improve on: - splitting pipes to separate flows (e.g one flow for stderr, one for stdout). Think of it as a graph. - native parallelization; I have to look in man every other time I use parallel.

> - splitting pipes to separate flows (e.g one flow for stderr, one for stdout). Think of it as a graph.

Could you elaborate a little on what you mean by this? bash already has the ability to redirect STDERR and STDOUT independently, and when you introduce named pipes into the mix things can get really fancy (probably too fancy, this is about where your script stops being a script and starts being a program written in perhaps the most inconvenient language available.)

Re: Four features that justify a new Unix shell

#24

OSH is probably a good incremental improvement over bash, but I also enjoy using the significantly more tradition-breaking Powershell with its object oriented nature. 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.

I should turn this into a FAQ, but PowerShell is natural on Windows, where the OS provides objects (either via the .NET VM, or COM and .DLLs, etc.)

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.

Re: Four features that justify a new Unix shell

#25
post #24

OSH is probably a good incremental improvement over bash, but I also enjoy using the significantly more tradition-breaking Powershell with its object oriented nature. 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.

I should turn this into a FAQ, but PowerShell is natural on Windows, where the OS provides objects (either via the .NET VM, or COM and .DLLs, etc.) 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…

Hadn't heard this story. Wouldn't they already have had some sort of ad relevance engine for Search?

Re: Four features that justify a new Unix shell

#26
post #24

OSH is probably a good incremental improvement over bash, but I also enjoy using the significantly more tradition-breaking Powershell with its object oriented nature. 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.

I should turn this into a FAQ, but PowerShell is natural on Windows, where the OS provides objects (either via the .NET VM, or COM and .DLLs, etc.) 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…

> JSON, YAML, XML, protobuf, msgpack, etc. not objects.

JavaScript Object Notation doesn't map well to objects?

Re: Four features that justify a new Unix shell

#27
post #13
post #10

Earlier quoted context omitted.

> It won't work. It would be like trying to convince people who are paid to write PHP not to write PHP. Many people have wasted breath on that, but important sites like Wikipedia are still written in hundreds of thousands of lines of PHP. If they're gonna keep writing bash, why would a new shell language help? > Even if a new line of shell never gets written, there will still be a huge installed base of shell scripts…

Because you can run your bash scripts with Oil. The tagline is: It's our upgrade path from bash to a better language and runtime. [1] It's basically the same as JS -> TypeScript, or PHP -> Hack. It's a saner language (and runtime) that runs existing code. ----- Shell is good for creating Unix systems because of the tools it provides. Ones that deal with the file system and heterogeneous processes (i.e. stuff you didn…

Seems like a big part of why shells are so much better for certain tasks is because of a failing of more general purpose languages. Working with the filesystem, spawning processes, and orchestrating io streams. Shells could almost be considered DSLs for these things, plus some session / state management.

So I think a good question is this: why can't we make these things equally easy to do in a more general purpose language?

Re: Four features that justify a new Unix shell

#28
post #26
post #24

Earlier quoted context omitted.

I should turn this into a FAQ, but PowerShell is natural on Windows, where the OS provides objects (either via the .NET VM, or COM and .DLLs, etc.) 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…

> JSON, YAML, XML, protobuf, msgpack, etc. not objects. JavaScript Object Notation doesn't map well to objects?

No, have you seem what kind of mish mash of a scheme most systems output? They'd be back to text processing anyway just making sure it returns the expected values.

Re: Four features that justify a new Unix shell

#29
post #26
post #24

Earlier quoted context omitted.

I should turn this into a FAQ, but PowerShell is natural on Windows, where the OS provides objects (either via the .NET VM, or COM and .DLLs, etc.) 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…

> JSON, YAML, XML, protobuf, msgpack, etc. not objects. JavaScript Object Notation doesn't map well to objects?

An object should have identify, state and behaviour. JSON only encodes state.

Re: Four features that justify a new Unix shell

#30

OSH is probably a good incremental improvement over bash, but I also enjoy using the significantly more tradition-breaking Powershell with its object oriented nature. 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.

Agreed... PowerShell is actually interesting and it feels a bit more like you're inside a shell-like REPL rather than just a fancy shell.

It's interesting until you run up against speed limitations both left and right. I still use it for some work and enjoy it, but it is by far the slowest technology I've used.
Post reply on HN