4 ms·

Are there any transpile to bash languages? I like the idea of a language that allows for a better experience in writing shell scripts -- and produces shell scr

Are there any transpile to bash languages? 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

kccqzy 6y ago
What do you think produces the traditional ./configure scripts that you run to configure an open source project prior to building it? Did some human write these ./configure scripts manually?
- codetrotter 6y ago
  Autoconf isn’t flexible enough for general purpose scripting though, is it? So not really relevant I think.
- viraptor 6y ago
  M4 doesn't really satisfy: > 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.
chubot 6y ago
(author here) Yeah I've been asked that before, and there are some things you can fix with a transpiler, but somethings you can't. 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 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.
- breatheoften 6y ago
  So is the normal usage path to start using osh for interactive use and then use osh in a bash compatible mode to write scripts that are less buggy but can still be run on bash? Or is it more common to write scripts that tend to then require the osh runtime exist in whatever context they are deployed to?
  - chubot 6y ago
    Right now, I use osh interactively in a very bash compatible mode. 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 Or this if I don't need to run with bash anymore: shopt --set oil:basic Example: https://github.com/oilshell/oil/blob/master/test/spec.sh#L9 https://github.com/oilshell/oil/blob/master/test/spec.sh#L9 docs in progress: https://www.oilshell.org/release/0.8.3/doc/oil-options.html 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 https://github.com/oilshell/oil/issues/463
toastal 6y ago
Tangentially you can use Dhall to get many types for Bash. You can have your options/configuration typed, then have Bash run a loop over it or whatever you need ho do.

kccqzy 6y ago

What do you think produces the traditional ./configure scripts that you run to configure an open source project prior to building it? Did some human write these ./configure scripts manually?

codetrotter 6y ago
Autoconf isn’t flexible enough for general purpose scripting though, is it? So not really relevant I think.
viraptor 6y ago
M4 doesn't really satisfy: > 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.

chubot 6y ago

(author here) Yeah I've been asked that before, and there are some things you can fix with a transpiler, but somethings you can't. 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 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.

breatheoften 6y ago
So is the normal usage path to start using osh for interactive use and then use osh in a bash compatible mode to write scripts that are less buggy but can still be run on bash? Or is it more common to write scripts that tend to then require the osh runtime exist in whatever context they are deployed to?
- chubot 6y ago
  Right now, I use osh interactively in a very bash compatible mode. 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 Or this if I don't need to run with bash anymore: shopt --set oil:basic Example: https://github.com/oilshell/oil/blob/master/test/spec.sh#L9 https://github.com/oilshell/oil/blob/master/test/spec.sh#L9 docs in progress: https://www.oilshell.org/release/0.8.3/doc/oil-options.html 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 https://github.com/oilshell/oil/issues/463

toastal 6y ago

Tangentially you can use Dhall to get many types for Bash. You can have your options/configuration typed, then have Bash run a loop over it or whatever you need ho do.