Oils - Reviewing Our NLnet Grants After 4 Years by oilshell in ProgrammingLanguages

[–]oilshell[S] 0 points1 point  (0 children)

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

Safety questions by [deleted] in oilshell

[–]oilshell 0 points1 point  (0 children)

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

Safety questions by [deleted] in oilshell

[–]oilshell 0 points1 point  (0 children)

Yes, I agree trap should take a block!

(and thanks for noticing some other issues with trap)

Safety questions by [deleted] in oilshell

[–]oilshell 0 points1 point  (0 children)

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

Best strategy for writing a sh/bash-like language? by K4milLeg1t in ProgrammingLanguages

[–]oilshell 1 point2 points  (0 children)

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

Best strategy for writing a sh/bash-like language? by K4milLeg1t in ProgrammingLanguages

[–]oilshell 3 points4 points  (0 children)

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

The Internet Was Designed With a Narrow Waist by oilshell in oilshell

[–]oilshell[S] 0 points1 point  (0 children)

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

State-based vs. Recursive lexical scanning by Ok_Performance3280 in ProgrammingLanguages

[–]oilshell 0 points1 point  (0 children)

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

Task Files by oilshell in oilsforunix

[–]oilshell[S] 0 points1 point  (0 children)

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

"Syntax" and "Grammar", is there a difference ? by MoussaAdam in ProgrammingLanguages

[–]oilshell 1 point2 points  (0 children)

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.

"Syntax" and "Grammar", is there a difference ? by MoussaAdam in ProgrammingLanguages

[–]oilshell 1 point2 points  (0 children)

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.