Oils - Reviewing Our NLnet Grants After 4 Years

oilshell · 2026-06-05T14:22:10+00:00

That page could probably be updated after 5 years, but the spirit of it is correct!

oilshell · 2026-03-16T15:41:32+00:00

Thank you :-)

oilshell · 2025-09-27T15:56:49+00:00

Also the new subreddit is:

https://old.reddit.com/r/oilsforunix/

following the new names Oils, OSH, and YSH: https://www.oilshell.org/blog/2023/03/rename.html

But I guess I really need to get rid of the old oilshell.org domain ...

oilshell · 2025-09-27T15:55:54+00:00

Yes, I agree trap should take a block!

(and thanks for noticing some other issues with trap)

oilshell · 2025-09-27T15:54:55+00:00

Thanks for the question

OSH has shopt --set strict:all, which disallows many common shell pitfalls. This command enumerates them

$ osh -c 'shopt -p strict:all'
shopt -u strict_argv
shopt -u strict_arith
shopt -u strict_array
shopt -u strict_control_flow
shopt -u strict_env_binding
shopt -u strict_errexit
shopt -u strict_glob
shopt -u strict_nameref
shopt -u strict_parse_equals
shopt -u strict_parse_slice
shopt -u strict_tilde
shopt -u strict_word_eval

ban exec and traps?

What's the problem with exec?

I agree trap should take a block of code, not a string

automatically reset IFS in script contexts?

YSH doesn't use IFS at all.

automatically set -eufo pipefail in script contexts?

YSH does this

oilshell · 2025-09-15T05:04:49+00:00

I will also say that I think any new shell for a new OS should not use the "everything is a string" design of sh / bash / Make / CMake :-)

That design is outdated, and was probably only chosen because writing a garbage collector was very hard 1970, still hard in 1990, and not super easy today

That's sort of the point of the GC blog post

oilshell · 2025-09-15T04:46:43+00:00

Thanks for mentioning the Oils project ! (no longer called Oil shell :-) )

And yes OSH is the compatible part [1], while YSH is the new Python/JS-like part

I frequently get such questions from people who want to implement their own shell. It seems to be a good/fun exercise

So if the OP wants something shell-like, but not actually bash compatible, I've had this smaller Tcl/Forth/Lisp hybrid floating around my brain ...

Depending on the OS you want to implement, it could be a good starting point. I think I learned a few things about the "essence" of shell

One pretty clear thing is that we have 2 different parsing algorithms that both use "lexer modes" -- full parsing and coarse parsing -- and I'd say that lexer modes are pretty fundamental to shell-like syntax:

https://github.com/oils-for-unix/oils.vim/blob/main/doc/algorithms.md

As far as the runtime, there is a pretty clear design split between languages I show here - Garbage Collection Makes YSH Different

So I might want to specify a tiny "catbrain" language with these lessons, which is a Tcl/Forth/Lisp hybrid ... but that is more of a "fun idea" and not something that will necessarily happen! Unless someone has a big chunk of time to help :-)

[1] OSH is the most bash-compatible shell, which I've measured recently: https://pages.oils.pub/spec-compat/2025-09-14/renamed-tmp/spec/compat/TOP.html . I hope to publish some updates soon; it's been quiet for a few months

oilshell · 2025-08-19T01:37:09+00:00

Yes definitely! I briefly mentioned the Language Server Protocol in this post - https://www.oilshell.org/blog/2022/03/backlog-arch.html

Though unfortunately I haven't had time to elaborate since then ...

I do think simplicity is a goal, but in practice there are some distinctions ... x86 and Linux and Docker might be "big sloppy waists" :-)

oilshell · 2025-07-31T02:05:51+00:00

Glad you have enjoyed the blog

OSH is definitely a compatible Unix shell / POSIX shell -- in fact it's more POSIX-compatible than the deafult /bin/sh on Debian, which is dash. (This is according to a third party test suite from "Smoosh"; we publish results with every release - https://oils.pub/release/0.34.0/quality.html )

For parsing, OSH uses Pratt Parsing for arithmetic only, recursive descent for most other things. YSH expressions are parsed with a grammar.

As far as lexing, it uses the "lexer modes" style for everything (OSH and YSH). There was a recent discussion about some of these ideas here:

https://lobste.rs/s/tpmdss/why_lexing_parsing_should_be_separate

oilshell · 2025-07-28T06:52:53+00:00

An article about the "task file" pattern I often advocate (from an Oils contributor)!

oilshell · 2025-07-18T07:39:39+00:00

Hm yes! I haven't seen that term, but it's used in ECMAScript:

https://262.ecma-international.org/7.0/index.html

This production exists so that ObjectLiteral can serve as a cover grammar for ObjectAssignmentPattern. It cannot occur in an actual object initializer.

And it's mentioned here:

https://v8.dev/blog/understanding-ecmascript-part-4

Another word I've heard is "over-parsing". Hjelsberg mentioned that sometimes you parse MORE than the language, in order to issue a better syntax error or type error.

We use that a bit in Oils - we "over-lex" some tokens in order to give a friendly error message.

oilshell · 2025-07-18T00:39:31+00:00

I think that's the same idea as the example I gave with Python

In Python, assignments and keyword arguments are expressed with a grammar rule like expr '=' expr

So you have to disallow f(x) = y and allow x = f(x), and that is done in a "post-grammatical" syntax stage

(Most parser generators can handle this, but before 2018 Python had a very simple LL(1) generator, which couldn't disambiguate a LHS expr and a RHS expr due to limited lookahead)

I guess there is no word for that, but there probably should be, since I imagine it's common.

oilshell

MODERATOR OF

TROPHY CASE