Hacker News new | past | comments | ask | show | jobs | submit login

I pretty much like the idea, but my biggest problem with current day shells is error handling.

Errexit (aka `set -e`) is a great idea badly executed. There are many things which can be improved (e.g. printing a stack trace by default), but at its core, there are two things which break it.

1. Inconsistent behavior: https://www.in-ulm.de/~mascheck/various/set-e/

2. You can't rely on it.

Inconsistent behavior should be no problem if a new cross-platform implementation is coming, but not being able to rely on it sucks. To give a quick demo:

  foo() {
    set -e
    echo "Sucks"
  printf 'Normal: %s\n' "$(foo)"
  printf 'Condition: %s\n'  "$(foo || true)"

  Condition: Sucks
So if someone is about to bring a new shell, please fix the error handling along the way. But hey, Yehuda Katz is part of the project. So I am looking forward to what is coming next :-)

After running into this and many other issues in sh/bash scripts (such as the pitfalls of handling newlines and spaces correctly with the splitting rules, the awkwardness of basic features such as lists or arithmetic, and the generally inconsistent and obscure syntax), I've moved all my shell scripts to Python3 and I have no regrets about it. Calling external programs is still very easy with the subprocess module. And it's installed pretty much everywhere you have sh/bash on.

To be fair, I am not even sure if creating a new shell scripting language is something worthwhile in this day and age. There's some value in the convenience of instantly turning a sequence of commands you just manually typed into a script, but there's a conflict in that the shell has to provide you a way to hack a sequence of actions together with as few characters as possible, while a script has to be comprehensible, maintainable and extensible. And the inertia you would have to overcome to successfully introduce a new programming language in addition to a new shell makes it intractable.

I have fixed this in https://oilshell.org/ :


Well actually there's one more thing I want to fix:


That will fix your case, because foo is a function, and the disabling of errexit in || is indeed problematic there.

Please subscribe to the bug, or feel free to e-mail at andy@oilshell.org if you want to know when it's fixed. I have another person "on the line" (author of envdir I believe) who also wants this fixed.

It would be great to have you both try this out and verify that errexit in Oil has no more pitfalls :)

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact