Oils 0.37.0 - Alpine Linux, YSH, and mycpp
48 points by andyc
48 points by andyc
This project is so cool. I love regtest/aports, that's a clever way to do regression testing.
Yes, what I like about it is that it's very precise! e.g. One fix caused a very subtle regression with an interaction of case and $(), and then the number of disagreements went from 12 to 17
Then fixing the bug made it go down again! It took awhile to get it that precise
I didn't get a chance to write about it, but I learned a ton about Linux containers through this experience
https://oils.pub/blog/2025/12/links.html#things-i-learned-about
Right now we are using chroot + OverlayFS; I may want to change that to crun + OverlayFS.
(Long story, but I think a complement to YSH is a Unix-y variant of OCI that's more composable and doesn't couple/conflate the executable format with storage and networking. crun is the container runtime that Podman uses, which is one reason we switched to podman)
shttp looks quite interesting. I think one major reason we avoid using bash for handling http request is because there are so many footguns when handling user input. Is this something that ysh now handles better?
Yes absolutely! Writing a CGI in either OSH or YSH is like doing it in Python or JavaScript.
In particular, you don't have this problem:
TIL: Some surprising code execution sources in bash -https://lobste.rs/s/mla0ns/til_some_surprising_code_execution
which is basically a "mini-ShellShock" vulnerability.
OSH and YSH don't confuse code and data. I would definitely not run CGI scripts in bash, but I would with OSH and YSH.
(with shell/OSH, you may have to be an expert to tell the difference between code and data ... but we don't have any confusion. With YSH it's more clear)
On a separate note, we found zero memory safety issues running Oils through decades of accumulated shell scripts in 8000+ packages!
We only found a single uncaught IndexError* exception, which was caused by a relatively recent change
The GC is solid, and makes Oils memory safe :-)
Also, I believe bash may have a botched solution to that problem ... shopt -s assoc_expand_once
Koichi Murase is both a bash contributor and Oils contributor, and argued against it
And then I saw this assoc_expand_once thread recently:
https://lists.gnu.org/archive/html/help-bash/2025-12/threads.html
What is the current (as of version 5.3 of bash) status of assoc_expand_once?
Is it necessary to set it? Is it on by default? What if you unset it?
My understanding is that it should be always on; is there any situation where you'd want it off?
There is no straight answer; it's still in progress:
Bottom line is that there might still be cases where setting `assoc_expand_once' is necessary, but I'm looking to decrease that number to 0.
(So why even have the option at all? was it botched?)
And then stuff like this:
Most of those work arounds above no long work with bash-5.2.
In bash-5.2.21, (( assoc[$var]++ )) (for non-empty $var) and (( assoc[.$var]++ )) appear to be safe even if $var contains ], , * or @.
They remain ACE vulnerabilities with older versions.
It's super confusing
As quoted here, "even bash isn't compatible with bash" - https://github.com/bashix-spec/bashix?tab=readme-ov-file
Oils has very compatible but less error prone assoc array semantics, done by me and Koichi Murase. (They can run large parts of ble.sh, the largest shell program in the world)
e.g. https://oils.pub/release/0.37.0/test/spec.wwz/osh-py/array-assoc.html