4 ms·

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

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.
paddim8 3y ago
I'm working on a shell language that combines these things. You can write things like: let column = du -h | str::column 0 echo(column[1..3])
kpcyrd 3y ago
For programming, I would gladly go with the second option in return for proper flow-control mechanics and data structures.

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.

paddim8 3y ago

I'm working on a shell language that combines these things. You can write things like: let column = du -h | str::column 0 echo(column[1..3])

kpcyrd 3y ago

For programming, I would gladly go with the second option in return for proper flow-control mechanics and data structures.