5 ms·

I really wish bash could evolve...in particular around control flow, variable assignment, string interpolation, and arithmetic. I love working with bash, but i

by chrsig 4y ago

I really wish bash could evolve...in particular around control flow, variable assignment, string interpolation, and arithmetic. I love working with bash, but it has some footguns that really require an expert hand. I know bash as-is will always be around for backwards compatibility with the god-knows-how-many scripts out there. It'd just be nice if there were a widely embraced path forward that kept the shell scripting spirit while shedding some of the unintuitive behaviors

kps 4y ago
Regarding the post topic, it's a shame bash hasn't embraced ksh93 getopts. This is enough to provide short and long options including help messages: usage=' [-1] [+NAME?cmd - XXX Synopsis here] [s:sample?XXX Sample option with argument]:[MODE] [v:verbose?XXX Show progress] file ...' while getopts "$usage" _ do typeset "opt_$_"="${OPTARG:-1}";; done shift OPTIND-1
johnchristopher 4y ago
I gave up on bash (more precisely on bashisms. edit: and because of bashims) and moved to dash or whatever is at /bin/sh. If it can't be done with ash/dash then I look into Python or node or PHP or what fits the situation best.
- skowalak 4y ago
  I did the same. I believe the biggest selling point of shell over other scripting languages is its availability on so many platforms. Unfortunately bashisms have ruined the effort of writing a one-size-fits-all script. So I, too, moved to POSIX shell syntax for the small problems and another shell scripting language for the bigger problems.
  - dwheeler 4y ago
    Bash is very widely available. If you use bashisms like arrays, just use bash as the first line.
    - ryapric 4y ago
      As the shebang (`#!`), I imagine you mean?
      - dwheeler 4y ago
        Yes, shebang.
oweiler 4y ago
I think there is a place for a transpile to Bash language, which just adds some tiny bits to fix Bash's idiosyncrasis
chubot 4y ago
Evolving bash, removing footguns, and providing a path forward is exactly what https://www.oilshell.org https://www.oilshell.org is about :) It's run thousands of lines of unmodified shell AND bash scripts for years, and provides an upgrade path to a new language. The new language is described here, and you can try it: https://www.oilshell.org/release/latest/doc/oil-language-tour.html https://www.oilshell.org/release/latest/doc/oil-language-tou... I've gotten some great feedback on it, but it's not stable yet. You can still influence the direction of the language (join us on Zulip) Latest release gives the status of the project: https://www.oilshell.org/blog/2023/03/release-0.14.2.html https://www.oilshell.org/blog/2023/03/release-0.14.2.html As an anecdote, one thing that was extremely difficult was fixing all the footguns around set -e / errexit in bash. In shell and bash, "you're damned if you do set -e and damned if yuo don't" However I believe we have done it: https://www.oilshell.org/release/0.14.2/doc/error-handling.html https://www.oilshell.org/release/0.14.2/doc/error-handling.h... We simply provide options to make sure that every exit code is checked. That's really all. But shells do NOT do this. In fact the standard specifies that shells shouldn't, which has left people mystified for decades. I've gotten good feedback about error handling and the rest of the changes. Again, you can try it right now if you want to verify that the footguns are indeed fixed.
- urxvtcd 4y ago
  > As an anecdote, one thing that was extremely difficult was fixing all the footguns around set -e / errexit in bash. Shameless plug: I've recently written a blog post about how set -e suddenly ceases to work when using function calls in flow control (what you refer to as "disabled errexit quirk"): https://snails.dev/posts/set-e.html https://snails.dev/posts/set-e.html Your comment made me interested in Oil, thanks!

by chrsig 4y ago

kps 4y ago

Regarding the post topic, it's a shame bash hasn't embraced ksh93 getopts. This is enough to provide short and long options including help messages: usage=' [-1] [+NAME?cmd - XXX Synopsis here] [s:sample?XXX Sample option with argument]:[MODE] [v:verbose?XXX Show progress] file ...' while getopts "$usage" _ do typeset "opt_$_"="${OPTARG:-1}";; done shift OPTIND-1

johnchristopher 4y ago

I gave up on bash (more precisely on bashisms. edit: and because of bashims) and moved to dash or whatever is at /bin/sh. If it can't be done with ash/dash then I look into Python or node or PHP or what fits the situation best.

skowalak 4y ago
I did the same. I believe the biggest selling point of shell over other scripting languages is its availability on so many platforms. Unfortunately bashisms have ruined the effort of writing a one-size-fits-all script. So I, too, moved to POSIX shell syntax for the small problems and another shell scripting language for the bigger problems.
- dwheeler 4y ago
  Bash is very widely available. If you use bashisms like arrays, just use bash as the first line.
  - ryapric 4y ago
    As the shebang (`#!`), I imagine you mean?
    - dwheeler 4y ago
      Yes, shebang.

oweiler 4y ago

I think there is a place for a transpile to Bash language, which just adds some tiny bits to fix Bash's idiosyncrasis

chubot 4y ago

Evolving bash, removing footguns, and providing a path forward is exactly what https://www.oilshell.org https://www.oilshell.org is about :) It's run thousands of lines of unmodified shell AND bash scripts for years, and provides an upgrade path to a new language. The new language is described here, and you can try it: https://www.oilshell.org/release/latest/doc/oil-language-tour.html https://www.oilshell.org/release/latest/doc/oil-language-tou... I've gotten some great feedback on it, but it's not stable yet. You can still influence the direction of the language (join us on Zulip) Latest release gives the status of the project: https://www.oilshell.org/blog/2023/03/release-0.14.2.html https://www.oilshell.org/blog/2023/03/release-0.14.2.html As an anecdote, one thing that was extremely difficult was fixing all the footguns around set -e / errexit in bash. In shell and bash, "you're damned if you do set -e and damned if yuo don't" However I believe we have done it: https://www.oilshell.org/release/0.14.2/doc/error-handling.html https://www.oilshell.org/release/0.14.2/doc/error-handling.h... We simply provide options to make sure that every exit code is checked. That's really all. But shells do NOT do this. In fact the standard specifies that shells shouldn't, which has left people mystified for decades. I've gotten good feedback about error handling and the rest of the changes. Again, you can try it right now if you want to verify that the footguns are indeed fixed.

urxvtcd 4y ago
> As an anecdote, one thing that was extremely difficult was fixing all the footguns around set -e / errexit in bash. Shameless plug: I've recently written a blog post about how set -e suddenly ceases to work when using function calls in flow control (what you refer to as "disabled errexit quirk"): https://snails.dev/posts/set-e.html https://snails.dev/posts/set-e.html Your comment made me interested in Oil, thanks!