u/oilshell

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

Thank you :-)

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 ...

Yes, I agree trap should take a block!

(and thanks for noticing some other issues with trap)

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

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

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

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" :-)

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

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

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.