4 ms·

Excellent explanation! However, I would disagree both that there isn't an easy fix and that each of the decisions are sensible. If the syntax to temporarily se

by pinusc 3y ago

Excellent explanation! However, I would disagree both that there isn't an easy fix and that each of the decisions are sensible. If the syntax to temporarily set variables was different, say using : instead of =, or requiring some delimiter between assignments and operations, or maybe enclosing the statement in braces (something like: {foo=bar; echo $foo}...) to delimit temporary assignments would have been reasonable alternatives, perhaps even more readable than this. Or having the sntax disallow `foo=`, requiring, say, `foo=null` or `foo=''`, which are both more explicit, or even `unset foo`. These are more sensible individual choices, and that's partly because they're more explicit and partly because they avoid a (now) common error. I'd argue good language design needs to think slightly bigger picture than "individually not catastrophic" choices. Sh is littered with a myriad of small bad choices, which add up to a language that's hard to code or script without bugs. Nowadays with shellcheck it's easier, but it shouldn't be necessary. The consensus is: it's a scripting language, it shouldn't be used for complex stuff. But if it was a slightly better scripting language, it _could_ be used more safely for larger or more complex scripts. The truth is that it's an ancient language, its (bad) syntax is set in stone, and there's nothing we can do about it except slowly move to alternatives. Sad that there's nothing established to take its place (Perl is read-only, python is not good enough as unix glue, everything else is too obscure). I know how and love to write in bash. But oh god was it painful to learn

__float 3y ago
> I know how and love to write in bash. But oh god was it painful to learn This is very well said :) > Sad that there's nothing established to take its place (Perl is read-only, python is not good enough as unix glue, everything else is too obscure). Is there anything notable? Either particularly well designed, or just popular? I think I've only ever heard of Oil (https://oilshell.org https://oilshell.org)
- gavinray 3y ago
  Ruby has very ergonomic and pleasant UX for doing the sorts of things you typically want to do in bash scripts IMO.
Izkata 3y ago
> or maybe enclosing the statement in braces (something like: {foo=bar; echo $foo}...) to delimit temporary assignments As long as you don't need to get anything out of it, it's a bit heavy but dropping to a subshell works like that: $ (foo=bar; echo $foo) bar $ echo $foo
Galanwe 3y ago
I don't think your comment fairly represents the situation. Bash is not _just_ a scripting language, it's also (and primarily) a shell. That means it needs to be good at both interactive REPL-style usage _and_ at simple scripting. Being a shell implies that it has to be exceptionally succinct and flexible about executing programs and manipulating environment variables. In that light, your comparison with Python and Perl don't make much sense. Would you enjoy replacing: $ cd /tmp $ ls -l with: $ os.chdir('/tmp') $ subprocess.run(['ls', '-l']) I guess not. Shells will always be a different breed of languages. Bash is maybe not the best at what it could be, but it's not the end of the world either. The example in the article is a bit silly to be honest. I think the result is kind of obvious for anyone half bash litterate.
- jhoechtl 3y ago
  > That means it needs to be good at both interactive REPL-style usage _and_ at simple scripting. The creators of powershell obviously were of a different opinion
  - Kwpolska 3y ago
    It is fairly good for interactive usage, there are aliases for common commands, case-insensitivity, tab completion etc.
- pinusc 3y ago
  You are right to point out that in my comment I talk about bash in terms of a language rather than just a shell; but I did have its shell-nature in mind while writing it, and in fact your example is exactly what I meant when I said that python is not good enough unix glue... there's a certain level of script complexity where python starts making more sense than bash, but because the ergonomics of calling other programs (unix glue!) or building pipelines are pretty poor, that threshold is pretty high. Some of bash syntax makes perfect sense in the context of a shell-but-also-scripting-language. Some of it makes perfect sense in the context of "everything is a string", which I think is an absolutely great abstraction---for example, unset variables being equivalent to empty strings. Other parts are just jargony, and might make the life of a few experienced shell-slingers slightly easier, while complicating many users' interactions with the shell. I suppose part of my point is that succintness here comes at the cost of readability. A shell could very well be _slightly_ more verbose than bash (say, requiring assignment operators to have two sides, so `foo=''` instead of `foo=`), still be plenty succint as a shell, but being slightly more explicit and readable in a scripting context. `foo=''` is only _two_ characters longer than `foo=`, and is already-implemented behavior. But the `foo=` syntax has certainly confused generations of unix users... that's just not a good tradeoff imo. I feel pretty comfortable calling this lack of foresight, or suboptimal design; that's not bashing (!) the language or its creators, rather, merely noting that we can do better. And if you don't think so... check out fish shell! It's a beloved and successful shell, and they forgo the use of = entirely (instead, you have to `set foo bar`, which is more verbose and a lot more explicit!) Edit: fish does allow `foo=bar echo $foo` to override variables, so they actually manage to keep bash ergonomics while avoiding mistakes while scripting.

by pinusc 3y ago

__float 3y ago

> I know how and love to write in bash. But oh god was it painful to learn This is very well said :) > Sad that there's nothing established to take its place (Perl is read-only, python is not good enough as unix glue, everything else is too obscure). Is there anything notable? Either particularly well designed, or just popular? I think I've only ever heard of Oil (https://oilshell.org https://oilshell.org)

gavinray 3y ago
Ruby has very ergonomic and pleasant UX for doing the sorts of things you typically want to do in bash scripts IMO.

Izkata 3y ago

> or maybe enclosing the statement in braces (something like: {foo=bar; echo $foo}...) to delimit temporary assignments As long as you don't need to get anything out of it, it's a bit heavy but dropping to a subshell works like that: $ (foo=bar; echo $foo) bar $ echo $foo

Galanwe 3y ago

I don't think your comment fairly represents the situation. Bash is not _just_ a scripting language, it's also (and primarily) a shell. That means it needs to be good at both interactive REPL-style usage _and_ at simple scripting. Being a shell implies that it has to be exceptionally succinct and flexible about executing programs and manipulating environment variables. In that light, your comparison with Python and Perl don't make much sense. Would you enjoy replacing: $ cd /tmp $ ls -l with: $ os.chdir('/tmp') $ subprocess.run(['ls', '-l']) I guess not. Shells will always be a different breed of languages. Bash is maybe not the best at what it could be, but it's not the end of the world either. The example in the article is a bit silly to be honest. I think the result is kind of obvious for anyone half bash litterate.

jhoechtl 3y ago
> That means it needs to be good at both interactive REPL-style usage _and_ at simple scripting. The creators of powershell obviously were of a different opinion
- Kwpolska 3y ago
  It is fairly good for interactive usage, there are aliases for common commands, case-insensitivity, tab completion etc.
pinusc 3y ago
You are right to point out that in my comment I talk about bash in terms of a language rather than just a shell; but I did have its shell-nature in mind while writing it, and in fact your example is exactly what I meant when I said that python is not good enough unix glue... there's a certain level of script complexity where python starts making more sense than bash, but because the ergonomics of calling other programs (unix glue!) or building pipelines are pretty poor, that threshold is pretty high. Some of bash syntax makes perfect sense in the context of a shell-but-also-scripting-language. Some of it makes perfect sense in the context of "everything is a string", which I think is an absolutely great abstraction---for example, unset variables being equivalent to empty strings. Other parts are just jargony, and might make the life of a few experienced shell-slingers slightly easier, while complicating many users' interactions with the shell. I suppose part of my point is that succintness here comes at the cost of readability. A shell could very well be _slightly_ more verbose than bash (say, requiring assignment operators to have two sides, so `foo=''` instead of `foo=`), still be plenty succint as a shell, but being slightly more explicit and readable in a scripting context. `foo=''` is only _two_ characters longer than `foo=`, and is already-implemented behavior. But the `foo=` syntax has certainly confused generations of unix users... that's just not a good tradeoff imo. I feel pretty comfortable calling this lack of foresight, or suboptimal design; that's not bashing (!) the language or its creators, rather, merely noting that we can do better. And if you don't think so... check out fish shell! It's a beloved and successful shell, and they forgo the use of = entirely (instead, you have to `set foo bar`, which is more verbose and a lot more explicit!) Edit: fish does allow `foo=bar echo $foo` to override variables, so they actually manage to keep bash ergonomics while avoiding mistakes while scripting.