3 ms·

All of these problems are fixed in OSH. It runs your bash scripts but you can also opt into correct error handling. The simple invariant is that it doesn't los

by chubot 4y ago

All of these problems are fixed in OSH. It runs your bash scripts but you can also opt into correct error handling. The simple invariant is that it doesn't lose an exit code, and non-zero is fatal by default. See https://www.oilshell.org/release/latest/doc/error-handling.html https://www.oilshell.org/release/latest/doc/error-handling.h... Oil 0.10.0 - Can Unix Shell Error Handling Be Fixed Once and For All? https://www.oilshell.org/blog/2022/05/release-0.10.0.html https://www.oilshell.org/blog/2022/05/release-0.10.0.html This took quite awhile, and I became aware of more error handling gotchas than I knew about when starting the project: e.g. it's impossible in bash to even see the error status of a process sub like diff <(sort left.txt) <(sort OOPS) If you have bash scripts that you don't want to rewrite, try 1) run them with OSH 2) Add shopt --set oil:upgrade at the top to get the error handling fixes. Tell me what happens :) https://github.com/oilshell/oil https://github.com/oilshell/oil I spent a long time on that, but the post didn't get read much. I think it's because it takes a lot of bash experience to even understand what the problem is. (rehash of https://news.ycombinator.com/item?id=33075915 https://news.ycombinator.com/item?id=33075915 which came up the other day :) )

maegul 4y ago
Never used OilShell (OSH) before, but this opening line on their home page struck me: > … and it's a new language for Python and JavaScript users who avoid shell! Why not work towards using python/JavaScript as shell languages? There was a HN thread a few days ago on Xonsh, the main python attempt at this which looks nice to me, which naturally got a lot of anti-anti-bash energy. But if we want better shell ergonomics and are willing to ditch bash, why not take popular versatile and capable languages and get them shell-appropriate? It seems like a natural use case for these languages, and even the place where they could retire to peacefully in the future. I suppose OSH is aiming at bash compatibility, but how good or viable is that really (not a rhetorical question)? Seems to me like an all or nothing thing as someone who recently ran into some bash-zsh incompatibility. ~~~ HN thread on Xonsh: https://news.ycombinator.com/item?id=33044772 https://news.ycombinator.com/item?id=33044772 Xonsh homepage: https://xon.sh/ https://xon.sh/
- Dylan16807 4y ago
  I tried xonsh for a while but it was just so slow to chdir a good fraction of the time that I gave up. (Running under WSL2, navigating around linux and windows directories.) Also looking up the syntax was awkward and I still had to copy and paste to make editing multi-line commands be sane.
- aidenn0 4y ago
  These questions are mostly addressed here: https://www.oilshell.org/blog/2021/01/why-a-new-shell.html#i-dont-understand-why-not-use-a-different-a-programming-language https://www.oilshell.org/blog/2021/01/why-a-new-shell.html#i... Note that osh is (really very nearly[1]) bash compatible by default, but you can opt in to incompatible parts. This lets you convert a large body of shell code gradually. 1: I think the only incompatibility is that in osh you can't index into associative arrays with unquoted words. IIRC this was to make parsing of osh decidable.
- matheusmoreira 4y ago
  > Why not work towards using python/JavaScript as shell languages? I always refer to this awesome answer to that question: https://stackoverflow.com/a/3640403/512904 https://stackoverflow.com/a/3640403/512904
  - maegul 4y ago
    Nice run down. But in this context it seems to boil down to > I have the feeling that trying to address these points by bolting features or DSLs onto a general-purpose programming language doesn't work. At least, I have yet to see a convincing implementation of it. … and what is worth doing, a new shell or new features in an old language, which isn’t addressed by that post AFAICT.
    - chubot 4y ago
      A short answer would be that dozens of projects like this already exist and have existed for decades (scsh was mentioned in this thread), and they aren't widely used as shell replacements: https://github.com/oilshell/oil/wiki/Internal-DSLs-for-Shell https://github.com/oilshell/oil/wiki/Internal-DSLs-for-Shell https://github.com/oilshell/oil/wiki/Alternative-Shells https://github.com/oilshell/oil/wiki/Alternative-Shells It doesn't mean they aren't useful, but we still need a better successor to Bourne shell / bash.
chubot 4y ago
Addendum: You need shopt --set oil:upgrade strict:all to catch this, or just use Oil. Demo here: https://news.ycombinator.com/item?id=33122256 https://news.ycombinator.com/item?id=33122256 They're separate things because introducing MORE error handling can make your script incompatible with bash, for people who want to write code that's portable to 2 shells :-/

by chubot 4y ago

maegul 4y ago

Never used OilShell (OSH) before, but this opening line on their home page struck me: > … and it's a new language for Python and JavaScript users who avoid shell! Why not work towards using python/JavaScript as shell languages? There was a HN thread a few days ago on Xonsh, the main python attempt at this which looks nice to me, which naturally got a lot of anti-anti-bash energy. But if we want better shell ergonomics and are willing to ditch bash, why not take popular versatile and capable languages and get them shell-appropriate? It seems like a natural use case for these languages, and even the place where they could retire to peacefully in the future. I suppose OSH is aiming at bash compatibility, but how good or viable is that really (not a rhetorical question)? Seems to me like an all or nothing thing as someone who recently ran into some bash-zsh incompatibility. ~~~ HN thread on Xonsh: https://news.ycombinator.com/item?id=33044772 https://news.ycombinator.com/item?id=33044772 Xonsh homepage: https://xon.sh/ https://xon.sh/

Dylan16807 4y ago
I tried xonsh for a while but it was just so slow to chdir a good fraction of the time that I gave up. (Running under WSL2, navigating around linux and windows directories.) Also looking up the syntax was awkward and I still had to copy and paste to make editing multi-line commands be sane.
aidenn0 4y ago
These questions are mostly addressed here: https://www.oilshell.org/blog/2021/01/why-a-new-shell.html#i-dont-understand-why-not-use-a-different-a-programming-language https://www.oilshell.org/blog/2021/01/why-a-new-shell.html#i... Note that osh is (really very nearly[1]) bash compatible by default, but you can opt in to incompatible parts. This lets you convert a large body of shell code gradually. 1: I think the only incompatibility is that in osh you can't index into associative arrays with unquoted words. IIRC this was to make parsing of osh decidable.
matheusmoreira 4y ago
> Why not work towards using python/JavaScript as shell languages? I always refer to this awesome answer to that question: https://stackoverflow.com/a/3640403/512904 https://stackoverflow.com/a/3640403/512904
- maegul 4y ago
  Nice run down. But in this context it seems to boil down to > I have the feeling that trying to address these points by bolting features or DSLs onto a general-purpose programming language doesn't work. At least, I have yet to see a convincing implementation of it. … and what is worth doing, a new shell or new features in an old language, which isn’t addressed by that post AFAICT.
  - chubot 4y ago
    A short answer would be that dozens of projects like this already exist and have existed for decades (scsh was mentioned in this thread), and they aren't widely used as shell replacements: https://github.com/oilshell/oil/wiki/Internal-DSLs-for-Shell https://github.com/oilshell/oil/wiki/Internal-DSLs-for-Shell https://github.com/oilshell/oil/wiki/Alternative-Shells https://github.com/oilshell/oil/wiki/Alternative-Shells It doesn't mean they aren't useful, but we still need a better successor to Bourne shell / bash.

chubot 4y ago

Addendum: You need shopt --set oil:upgrade strict:all to catch this, or just use Oil. Demo here: https://news.ycombinator.com/item?id=33122256 https://news.ycombinator.com/item?id=33122256 They're separate things because introducing MORE error handling can make your script incompatible with bash, for people who want to write code that's portable to 2 shells :-/