Comment by jitl | Hacker News Reader

Comment by jitl | Hacker News Reader

Here's what the plan seems to be from reading the blog and the README:

1. Re-implement Bash and similar shells in a modern programming environment with an eye to extensibility

2. Make good debugging tools because this is now easier because (1).

3. Create a new language that extends Bash, similar to how ES6 extends ES5, for a gentle migration of large shell scripts to a safer language

What, other than static parsing, should this endgame language offer? Where does it fall, on the gamut from Bash to Haskell? We already have quite a few languages that offer a souped-up scripting experience.

When my bash programs become too long, I usually reach for Ruby, which has convenient back-ticks syntax for shelling out, and many convenience methods on its built-in types for mashing strings and such. But like Bash, too much ruby eventually becomes an unmaintainable mess without strict standards enforcement. What will Oil offer for me, over Ruby?

Here's how I'd order existing languages on a scale from Bash to Haskell:

1. Bash with `set -e`

2. Perl

3. TCL (has declared arguments, after all...)

4. Ruby

5. Python

6. Golang

7. Java

8. C++

9. Ocaml

10. Haskell

Good questions. It's clear from this comment thread that I need to explain Oil better on the blog (which I mentioned in the conclusion), but I'll respond here briefly.

I somewhat agree with your spectrum of strictness, but the other dimension is "how suited is this language for shell-like problems?".

C++ is strict, but obviously not good for writing "shell scripts" in.

Oil will be somewhere around Python in terms of strictness, but at least as suitable as bash for shell-like problems (of course). The goal is for it to be more suitable, but I haven't gotten there yet.

As far as what it offers, that is scattered over the blog, but this tag might give an idea:

http://www.oilshell.org/blog/tags.html?tag=oil-language#oil-...

As a concrete example, Oil will be based more around arrays of strings than flat strings. The "Thirteen Awkward Ways..." post hints at that. FWIW, the Ion shell, part of Redox OS, was influenced by this way of thinking.

Also, I need to write a blog post entitled "Python Is Not an Acceptable Shell". There was a nice blog post that translated shell to Python that inadvertently proved this point.

I'll keep your questions in mind when writing future posts explaining the project.

If you're going to solve the problem of shell scripting, one particular itch that I have is that shell scripts, or at least the sufficiently complex ones, are often strongly dependent on availability of local executables, sometimes even specific implementations or versions.

I had a shell script on my desktop that would automagically extract any archive I threw at it. Nice. So when I was working on android through a shell, I wanted the same convenience and so I scp'd the script onto my phone. It wouldn't run. Only worked with GNU tar, as opposed to any other tar, like bsd tar or busybox's.

Having a language that provides system-independent abstractions of ls, tar, top, or the other way, that clearly indicates upon which binaries it depends, would greatly improve script usability.

It'd be nice if running an oil script would automatically warn me that I need GNU tar >= version x.xx.

> Here's how I'd order existing languages on a scale from Bash to Haskell: > snip

I don't think you can just compare languages that way. There's more than one axis. For instance, to say python, then java, then c++ seems backwards in terms of writing scripts because c++ is much more suited for that. But it's also backwards for the purpose of writing applications, because they're all around the same place, albeit in different ways. It's not so simple as saying "here are these languages, here's where they lie on a scale from bash to haskell", because there is no scale from bash to haskell.

I agree, I personally can justify moving to a new shell. Bash is horrific to script in, compared to most everything else. It’s sole advantage for me is that it’s almost literally the default everywhere.

A fun problem I play with sometimes: eek out a small-but-super-powerful subset of standard shell tools (sh, awk). For example, if you could create a forth in a dozen lines of bash, then you could just recreate it whenever you needed it.

Then you could start refactoring code to it. Easier than a rewrite.

I got quite far along at building a message-driven paradigm in awk. The input is a stream of well-defined messages. As you read it, append new messages to the end of the stream. I found that the awk I was using (gnu I think) was complicated by IO buffering behaviour. Still, an interesting problem space.

Lex may offer strong opportunities too, although is not part of the posix base.

I think this is a neat idea. I also think I would not want to touch this code base. Then again, I rarely want to touch the relatively simple messy bash scripts I write either.

11. Lisp

Reply on news.ycombinator.com