Why Create a New Unix Shell?

It's only tangential but switching to fish shell made me about 3 times more productive. Being able to easily recall commands, to have completions displayed as I type, and to have interactivity be a first class citizen of the environment... made working in the shell so so so so much nicer.

Fish has its own quirks, some of which seem unnecessary, but it was a godsend. There is definitely still room for improvement of the old tools, a. lot. of. room.

Greetings!

First off, any person who would write either a language or a shell, now or in the future, should read your page, and in fact, should read everything about your Oil shell/language...

It's a laudable effort!

This page is going to my HN favorites, for future review.

What follows next are my thoughts about selected excerpts of text on the page (please don't interpret as criticism, that's not the intent):

>"You can think of a Unix shell in two ways:

1. As a text-based user interface. You communicate with the operating system by typing commands.

2. As a language. It has variables, functions, and loops. Shell programs are text files that start with #!/bin/sh."

[...]

>"Are you reinventing Perl?

It's true that Perl is closer to shell than Python and Ruby are. For example, the perl -pie idiom can take the place of awk and sed. However, Perl isn't an acceptable shell either:

o It doesn't have true pipelines (of processes). I believe you have to "shell out" for this.

o It doesn't have a concept of file descriptor state. How do you write the equivalent of my_shell_func 2> err.txt, where my_shell_func can invoke both functions and external commands?

o Perl has a function called grep(), but the real grep is better for many problems."

PDS: This touches upon a historic problem, which is basically that either:

A) Shell designers work their way "up" to a programming language, in which case some elegant programming language features are either not thought about, or not thought deeply enough about, and thus either not implmented, or implemented poorly / "non-orthagonally", AKA a "Kludge".

Or:

B) Language designers work their way "down" to supporting shell commands / a shell subsystem -- in which case some elegant shell features are either not thought about, or not thought deeply enough about, and thus either not implmented, or implemented poorly / "non-orthagonally", AKA a "Kludge".

Also, languages are typically too heavy in what they require typed for shell-scripters, and shells are typically too light in what they allow (and error checking/debugging features) for programmers writing large programs...

If someone were to design the most ideal programming language which also can be used for shell scripting, they'd have to look at things from both perspectives, and they'd have to create a language/shell -- completely balanced "down the middle" between these two paradigms...

Perhaps the Oil shell/programming language -- is, or will become that middle line...

To that extent, I wish you a lot of luck!

If I were going to go down this path, I'd look at "first principles" (Elon Musk):

The greatest differentiator between shell commands and lines of code in most programming languages is the point you alluded to in your comparison with Perl:

"o It doesn't have true pipelines (of processes). I believe you have to "shell out" for this."

In other words, in most programming languages (unless you are using threads), you are guaranteed linear execution.

In a Unix shell -- because you can run multiple commands that may take varying amounts of time to complete, this guarantee is no longer present...

That would be the fundamental thing to keep in mind when writing this future language/shell...

(A good program to test when writing this language would be a Web-server -- where the base server is a single script, and then when it detects a connection, passes this over to either a single separate command-line invoked Unix program or script comprising multiple such Unix programs linked with pipes, but the central "server" script has to handle a whole lot of simultaneous I/O from multiple such separate programs (it centralizes database access!), and do this in a simple way that script programmers would be comfortable with, while guaranteeing the correct data flows...)

Anyway, wishing you luck in this endeavor!

Oil looks interesting. The documentation is compelling.

I sleep at night by writing stoic bash. If I encounter anything unexpected in a script I don’t try to handle it, I just report it and then crash.

Most of the bash contortions I’ve seen in my life happen when people (myself included) have tried to handle error conditions or ill specified inputs, gracefully.

A bash script is like a pre-flight checklist: a list of things that should work to get something going. Most bash scripts are like this: in general they are sequences of commands to change the system from one good state to another, not to recover it from a bad state.

In the analogy: if something is not ok with your aircraft it’s beyond the scope of the pre flight check to fix it. Don’t use the checklist as a way of trying to automatically detect what the error is in order to fix it.

Why do you remap Ctrl-C?

I think the author realized something important. There's the bash as a CLI users and bash as a scripting language users. I'm firmly in camp one and I think it's an important difference to realize.

I don't want my CLI to be a REPL for a scripting language. It's something I really disliked about PowerShell when I tried it. It just felt like a dotnet scripting language and not like a CLI.

If Oil provides a scripting interface with structured types etc. I'm all for it. I just don't want to have to deal with it when using the shell interactively. I love it when writing scripts and programs, but not for interactive shell use.