I like the idea of a language that allows for a better experience in writing shell scripts -- and produces shell scripts with fewer bugs on the output side.
But i wonder if a transpile approach wouldn't be better in the long run
That's why the tagline to Oil is now "our upgrade path from bash to a better language AND RUNTIME".
The shell runtime needs to be fixed too, e.g. the error handling mentioned in the blog post and that I follow up on here: https://news.ycombinator.com/item?id=24872986
You might be able to compile that to some really long bash, but I don't think it works in general, because editing deployed scripts to fix stuff is useful (yes in production, but also on your own machine. Think of all the shell that people put on it, like virtualenv, nix-shell, rustup, etc.)
You don't want to end up with the JavaScript problem: you have a dynamic language, but ALSO A BUILD PROCESS, which is basically the worst of both worlds.
Or is it more common to write scripts that tend to then require the osh runtime exist in whatever context they are deployed to?
Then at the top of my scripts I put this if I still want to run with bash:
shopt -s strict:all 2>/dev/null || true
shopt --set oil:basic
docs in progress: https://www.oilshell.org/release/0.8.3/doc/oil-options.html
Having the OSH runtime exist everywhere is something we should work on: https://github.com/oilshell/oil/issues/463
> better experience in writing
It will happily transform a small mistake into garbage. Then you have to debug both the transformed result and the original script to match up what you intended.