7 ms·

> Bash is not a "real" programming language, so do not treat it as one. Is there a reason we aren’t using a shell with a proper programming language for script

> Bash is not a "real" programming language, so do not treat it as one. Is there a reason we aren’t using a shell with a proper programming language for scripting? I can’t say I’m a fan of bashscript. I wonder why we are using this weird language.

jrochkind1 5y ago
Because cross-OS (not just cross-linux-distro but even that) standards-making doesn't exist anymore in a real non-broken way, and we're stuck with whatever standards of 20+ years ago. Whether official or de facto (technically bash is just de facto although `bash --posix` or `sh` is an official real standard). There basically isn't any "innovation" happening in this space in a way that could really result in anything as pervasive as bash. Maybe also cause it's just not "interesting" anymore, the 'sexy' things are many levels of abstraction higher than they were when bash came to dominance. It feels like now we're just stuck with it forever, indeed.
- m3at 5y ago
  I agree with your broader point that we seem stuck with old shells and no contenders seems in a position to replace them. However some are certainly trying, like osh [1] that takes backwards compatibility with bash seriously, which makes adoption easier. Maybe it'll be like the C++ vs Rust situation? https://www.oilshell.org/ https://www.oilshell.org/
- quotemstr 5y ago
  Maybe it's time for some other body --- say, freedesktop.org --- to start standardizing things that have traditionally been in the domain of POSIX. After all, HTML got much better when WHATWG took W3C's toys away and actually started innovating HTML again. Maybe it's time to do something similar with Unix: I'm sick and tired of people telling everyone that we have to stay in some 1995 time capsule because we need to follow The Standard and if The Standard hasn't changed, too bad.
- majormajor 5y ago
  You say "don't exist anymore" but when was it better? Pre-Mac-OS-X you didn't even have an easy to access shell there on Macs, and Windows wasn't bash either. So if there was a golden era for that, it never included the two predominant desktop OSes. De-facto standardization has at least brought us free officially-supported options for running Bash or other *nix shells on both of those platforms(if terribly outdated on Mac).
- registeredcorn 5y ago
  > Because cross-OS (not just cross-linux-distro but even that) standards-making doesn't exist anymore in a real non-broken way, and we're stuck with whatever standards of 20+ years ago. As someone who's struggled to grasp some of the finer points of programming, OS, etc. can you expand on this a bit? Why is it that standards have gone the way they have?
sodapopcan 5y ago
My feeling is that it is about convenience when typing at the terminal. Having a unified language for both scripting and entering commands is quite convenient. Also, bare strings while typing at the terminal is very convenient! It would be really annoying if we always had to add quotes for string args when we're typing at the terminal: $ cat "file.txt" ...and I don't even know what options would look like... maybe: $ ls "*.txt", ["l", "a"] I dunno... this would mean we'd probably need parens now for precedent-type concerns: $ ls("*.txt", ["l", "a"]) > "file.txt" Anyway, that is why I understood that it's this way. I can't point to a resource about it, though.
- jandrese 5y ago
  You look like you are just about to discover Powershell.
  - psyclobe 5y ago
    Powershell is how I instrument cross platform CI scripting, with the power of the module concept and manifess now you can write real powerful type safe apis that can run anywhere. It has its quirks though...
    - joombaga 5y ago
      Any gotchas with running the same scripts on Windows and Linux? I've been thinking about switching to PowerShell. Love it on Windows. Never tried it on Linux but I did try it on macOS a few years ago and remember some quirks. Currently a bash (over)user.
      - psyclobe 5y ago
        One gotcha is powershell core has some different apis then the 'windows powershell', best to deploy core on both systems to unify the api. Also powershell has no support for automatically handling external shell commands that error, you must manually check $LASTEXITCODE (easily done with a custom invoke api that you use for everything). Also well, some of the escaping in strings is really odd...
rovr138 5y ago
Perl used to be used a lot to automate things. I feel Python has taken some of that, but also have seen Bash being picked up more.
- midasuni 5y ago
  I tend to start writing things in bash (piping into things like grep, tac, sed, etc However if I’m not careful they get painfully complex and I tend to regret not writing it in perk. As such I now switch to using Perl when I get to the function stage, or anything other than the most simple bash arithmetic.
throwaway984393 5y ago
If you want to choose a programming language, there are hundreds to choose from. You could write a small program ("script") in Brainfuck. But that would be really annoying, and it would take you a long time to get anything done. Other languages may also take a long time to write, test, execute, and maintain. And they may be better at some things than others. You have to step back and remember the point of all this. Why are you programming? To solve a problem, and make a human's life easier. What is the problem you are trying to solve? How can we make the human's life easier? In this case, it's "I want to combine bunch of programs together in a command-line interface, to make it easier to use these programs to get my work done on the command-line." So, what solution should we choose for this scenario? Lots of different "scripting" languages exist (we used to call them "glue languages"). Today Python is the most popular, and before it was PHP and Perl. But who cares if they're popular? What are they good for? Why would you choose one over the other? Python is a general purpose language which is easy to learn, easy to write, and easy to read. Well that sounds nice, but it's very "general" and not specific to our use case. PHP is a language designed for use in web development. Perl is a language designed for system administration-type tasks. Bash scripting is designed for making it easy to combine already-existing programs in a command-line shell, with no modification or creation of programs required. The only "dependency" is the Bash interpreter (which happens to also be the command-line interface we started our problem with! how convenient!) and an existing collection of software tools that work with each other through a command-line interface. Every part of it is explicitly not designed to "make programming easier". Instead, it is designed to make "combining programs in the command-line" easier. The result is things like every single word you type is potentially just an outside program being executed, or arguments to that program. No other language has this quirky behavior, because they're not designed solely to make command-lines easier to use. I know Perl well, and the language is fantastically useful as a system scripting language. It combines some of the best features of common shell scripting programs with more programming language-specific features. It is designed with shortcuts and "magic" to make quick work of command-line scripting tasks. But ultimately Perl was not built into the command-line, so its utility is always a bit stilted. Going between the shell and the Perl code and back to the shell isn't as flexible as if the Perl code was embedded in the command-line. Perl also doesn't have as simple a facility for pipes as a command-line shell does. Oh, and a Perl install is rather large, isn't available everywhere by default (anymore), and has all the usual dependency problems. So even though I know Perl very well, if I need to just combine existing programs in the command-line, I always use Shell scripting instead of Perl. (There are Perl shells which solve this problem, but then everyone needs to learn Perl, and Perl can be.... idiosyncratic) You could also use Awk for a large number of general programming tasks, but again it's designed for a different specific problem: pattern-scanning and processing, not generally combining programs together. So we use shell scripting to solve the problem because it was designed specifically for our problem, it's ubiquitous, and simple to use. You could use any other programming language, but it wouldn't fit our scenario as well. Once your use case changes, and you are no longer only trying to combine existing programs together, or the existing programs don't do what you want them to do, then you need to use a different language that better fits that new use case.
nextaccountic 5y ago
ruby in some cases feel just like shell scripting, even more than perl.. you can even do piping to chain two commands together https://stackoverflow.com/questions/4234119/ruby-pipes-how-do-i-tie-the-output-of-two-subprocesses-together https://stackoverflow.com/questions/4234119/ruby-pipes-how-d... (edit: using the shell library https://github.com/ruby/shell https://github.com/ruby/shell so, not out of box in ruby, unfortunately, which is a mortal sin for replacing bash in scripts =/) Here are the ways to run a program in ruby https://stackoverflow.com/questions/7212573/when-to-use-each-method-of-launching-a-subprocess-in-ruby https://stackoverflow.com/questions/7212573/when-to-use-each...
heavyset_go 5y ago
It's because Bash is everywhere and is thus the next least common denominator after sh.
- chasil 5y ago
  Bash is not everywhere. There are two very distinct places where Bash is not, that I have found. Bash is not in busybox. It pretends to be, but what is really there is the Almquist shell, with a bit of syntactic sugar to silence the common complaints. Bash is also not in Debian's shell (/bin/sh). In that place, there is no tolerance of bashisms. It is important to know the POSIX shell for these reasons.
  - jude- 5y ago
    Bash is readily available everywhere, though. Is there a widely used OS that cannot run bash, but can run BusyBox ash or dash?
    - chasil 5y ago
      Bash is not used in Android. The Android userland explicitly avoids any GPL software. The Android system shell is the MirBSD Kornshell (mksh). This is (obviously) a massive platform.
      - jude- 5y ago
        But, you can nevertheless install bash on Android. That was my ask -- show me a widely-used OS that cannot run bash but can run other similar shells.
  - gkfasdfasdf 5y ago
    > Bash is also not in Debian's shell (/bin/sh). In that place, there is no tolerance of bashisms. When writing a bash script, shouldn't you be setting the shebang to /bin/bash which is available on Debian?
    - 5y ago
pajko 5y ago
There's csh.
- mgerdts 5y ago
  In about 1995 I asked the question "how can a shell intended for C programmers not support functions?" I've still not found a suitable answer.
- deleted 5y ago
  [deleted]
chasil 5y ago
Stephen Bourne was a great fan of ALGOL, and had C preprocessor directives to "ALGOLify" C. https://research.swtch.com/shmacro https://research.swtch.com/shmacro The Bourne shell thus adopted ALGOL syntax, distinct from anything else in UNIX. David Korn brought a pile of C, and wedged it into a max 64k program space (for Xenix), and his upward-compatible Korn shell (ksh88) had many, many features. Then there were the "UNIX Wars"... https://en.wikipedia.org/wiki/Unix_wars https://en.wikipedia.org/wiki/Unix_wars The fallout of this was the choice of a few Korn features, but not all (no arrays, coprocesses, [some] eval, regex, et al.) The wars defined the POSIX shell. Yes, it can be infuriating.
popcube 5y ago
shell is good enough, when people started to use script language, they just wanted to fill the empty between bash and C, no one want to replace it, so bash and other shell still there
lmm 5y ago
I don't know why "we" are. Just use Python. Or whatever language you're using for your main system (I've written "scripts" in Scala, sure it takes a second or two to warm up the JVM but it's honestly fine). Or TCL if you really must have a language that can be used as a login shell.
bsder 5y ago
> Is there a reason we aren’t using a shell with a proper programming language for scripting? Mostly because the people who want to introduce a "programming language" into the shell don't prioritize being a shell. Check out the "Oh" shell for contrast. This is what a programming language looks like when you force it to conform to being a shell first priority. https://github.com/michaelmacinnis/oh https://github.com/michaelmacinnis/oh https://www.youtube.com/watch?v=v1m-WEZz46U https://www.youtube.com/watch?v=v1m-WEZz46U This is "Scheme-like" (actually the late John Shutt's Kernel-like) but has FEXPRs so things can be redefined and evaluation can be controlled.

jrochkind1 5y ago

Because cross-OS (not just cross-linux-distro but even that) standards-making doesn't exist anymore in a real non-broken way, and we're stuck with whatever standards of 20+ years ago. Whether official or de facto (technically bash is just de facto although `bash --posix` or `sh` is an official real standard). There basically isn't any "innovation" happening in this space in a way that could really result in anything as pervasive as bash. Maybe also cause it's just not "interesting" anymore, the 'sexy' things are many levels of abstraction higher than they were when bash came to dominance. It feels like now we're just stuck with it forever, indeed.

m3at 5y ago
I agree with your broader point that we seem stuck with old shells and no contenders seems in a position to replace them. However some are certainly trying, like osh [1] that takes backwards compatibility with bash seriously, which makes adoption easier. Maybe it'll be like the C++ vs Rust situation? https://www.oilshell.org/ https://www.oilshell.org/
quotemstr 5y ago
Maybe it's time for some other body --- say, freedesktop.org --- to start standardizing things that have traditionally been in the domain of POSIX. After all, HTML got much better when WHATWG took W3C's toys away and actually started innovating HTML again. Maybe it's time to do something similar with Unix: I'm sick and tired of people telling everyone that we have to stay in some 1995 time capsule because we need to follow The Standard and if The Standard hasn't changed, too bad.
majormajor 5y ago
You say "don't exist anymore" but when was it better? Pre-Mac-OS-X you didn't even have an easy to access shell there on Macs, and Windows wasn't bash either. So if there was a golden era for that, it never included the two predominant desktop OSes. De-facto standardization has at least brought us free officially-supported options for running Bash or other *nix shells on both of those platforms(if terribly outdated on Mac).
registeredcorn 5y ago
> Because cross-OS (not just cross-linux-distro but even that) standards-making doesn't exist anymore in a real non-broken way, and we're stuck with whatever standards of 20+ years ago. As someone who's struggled to grasp some of the finer points of programming, OS, etc. can you expand on this a bit? Why is it that standards have gone the way they have?

sodapopcan 5y ago

My feeling is that it is about convenience when typing at the terminal. Having a unified language for both scripting and entering commands is quite convenient. Also, bare strings while typing at the terminal is very convenient! It would be really annoying if we always had to add quotes for string args when we're typing at the terminal: $ cat "file.txt" ...and I don't even know what options would look like... maybe: $ ls "*.txt", ["l", "a"] I dunno... this would mean we'd probably need parens now for precedent-type concerns: $ ls("*.txt", ["l", "a"]) > "file.txt" Anyway, that is why I understood that it's this way. I can't point to a resource about it, though.

jandrese 5y ago
You look like you are just about to discover Powershell.
- psyclobe 5y ago
  Powershell is how I instrument cross platform CI scripting, with the power of the module concept and manifess now you can write real powerful type safe apis that can run anywhere. It has its quirks though...
  - joombaga 5y ago
    Any gotchas with running the same scripts on Windows and Linux? I've been thinking about switching to PowerShell. Love it on Windows. Never tried it on Linux but I did try it on macOS a few years ago and remember some quirks. Currently a bash (over)user.
    - psyclobe 5y ago
      One gotcha is powershell core has some different apis then the 'windows powershell', best to deploy core on both systems to unify the api. Also powershell has no support for automatically handling external shell commands that error, you must manually check $LASTEXITCODE (easily done with a custom invoke api that you use for everything). Also well, some of the escaping in strings is really odd...

rovr138 5y ago

Perl used to be used a lot to automate things. I feel Python has taken some of that, but also have seen Bash being picked up more.

midasuni 5y ago
I tend to start writing things in bash (piping into things like grep, tac, sed, etc However if I’m not careful they get painfully complex and I tend to regret not writing it in perk. As such I now switch to using Perl when I get to the function stage, or anything other than the most simple bash arithmetic.

throwaway984393 5y ago

If you want to choose a programming language, there are hundreds to choose from. You could write a small program ("script") in Brainfuck. But that would be really annoying, and it would take you a long time to get anything done. Other languages may also take a long time to write, test, execute, and maintain. And they may be better at some things than others. You have to step back and remember the point of all this. Why are you programming? To solve a problem, and make a human's life easier. What is the problem you are trying to solve? How can we make the human's life easier? In this case, it's "I want to combine bunch of programs together in a command-line interface, to make it easier to use these programs to get my work done on the command-line." So, what solution should we choose for this scenario? Lots of different "scripting" languages exist (we used to call them "glue languages"). Today Python is the most popular, and before it was PHP and Perl. But who cares if they're popular? What are they good for? Why would you choose one over the other? Python is a general purpose language which is easy to learn, easy to write, and easy to read. Well that sounds nice, but it's very "general" and not specific to our use case. PHP is a language designed for use in web development. Perl is a language designed for system administration-type tasks. Bash scripting is designed for making it easy to combine already-existing programs in a command-line shell, with no modification or creation of programs required. The only "dependency" is the Bash interpreter (which happens to also be the command-line interface we started our problem with! how convenient!) and an existing collection of software tools that work with each other through a command-line interface. Every part of it is explicitly not designed to "make programming easier". Instead, it is designed to make "combining programs in the command-line" easier. The result is things like every single word you type is potentially just an outside program being executed, or arguments to that program. No other language has this quirky behavior, because they're not designed solely to make command-lines easier to use. I know Perl well, and the language is fantastically useful as a system scripting language. It combines some of the best features of common shell scripting programs with more programming language-specific features. It is designed with shortcuts and "magic" to make quick work of command-line scripting tasks. But ultimately Perl was not built into the command-line, so its utility is always a bit stilted. Going between the shell and the Perl code and back to the shell isn't as flexible as if the Perl code was embedded in the command-line. Perl also doesn't have as simple a facility for pipes as a command-line shell does. Oh, and a Perl install is rather large, isn't available everywhere by default (anymore), and has all the usual dependency problems. So even though I know Perl very well, if I need to just combine existing programs in the command-line, I always use Shell scripting instead of Perl. (There are Perl shells which solve this problem, but then everyone needs to learn Perl, and Perl can be.... idiosyncratic) You could also use Awk for a large number of general programming tasks, but again it's designed for a different specific problem: pattern-scanning and processing, not generally combining programs together. So we use shell scripting to solve the problem because it was designed specifically for our problem, it's ubiquitous, and simple to use. You could use any other programming language, but it wouldn't fit our scenario as well. Once your use case changes, and you are no longer only trying to combine existing programs together, or the existing programs don't do what you want them to do, then you need to use a different language that better fits that new use case.

nextaccountic 5y ago

ruby in some cases feel just like shell scripting, even more than perl.. you can even do piping to chain two commands together https://stackoverflow.com/questions/4234119/ruby-pipes-how-do-i-tie-the-output-of-two-subprocesses-together https://stackoverflow.com/questions/4234119/ruby-pipes-how-d... (edit: using the shell library https://github.com/ruby/shell https://github.com/ruby/shell so, not out of box in ruby, unfortunately, which is a mortal sin for replacing bash in scripts =/) Here are the ways to run a program in ruby https://stackoverflow.com/questions/7212573/when-to-use-each-method-of-launching-a-subprocess-in-ruby https://stackoverflow.com/questions/7212573/when-to-use-each...

heavyset_go 5y ago

It's because Bash is everywhere and is thus the next least common denominator after sh.

chasil 5y ago
Bash is not everywhere. There are two very distinct places where Bash is not, that I have found. Bash is not in busybox. It pretends to be, but what is really there is the Almquist shell, with a bit of syntactic sugar to silence the common complaints. Bash is also not in Debian's shell (/bin/sh). In that place, there is no tolerance of bashisms. It is important to know the POSIX shell for these reasons.
- jude- 5y ago
  Bash is readily available everywhere, though. Is there a widely used OS that cannot run bash, but can run BusyBox ash or dash?
  - chasil 5y ago
    Bash is not used in Android. The Android userland explicitly avoids any GPL software. The Android system shell is the MirBSD Kornshell (mksh). This is (obviously) a massive platform.
    - jude- 5y ago
      But, you can nevertheless install bash on Android. That was my ask -- show me a widely-used OS that cannot run bash but can run other similar shells.
- gkfasdfasdf 5y ago
  > Bash is also not in Debian's shell (/bin/sh). In that place, there is no tolerance of bashisms. When writing a bash script, shouldn't you be setting the shebang to /bin/bash which is available on Debian?
  - 5y ago

pajko 5y ago

There's csh.

mgerdts 5y ago
In about 1995 I asked the question "how can a shell intended for C programmers not support functions?" I've still not found a suitable answer.
deleted 5y ago
[deleted]

chasil 5y ago

Stephen Bourne was a great fan of ALGOL, and had C preprocessor directives to "ALGOLify" C. https://research.swtch.com/shmacro https://research.swtch.com/shmacro The Bourne shell thus adopted ALGOL syntax, distinct from anything else in UNIX. David Korn brought a pile of C, and wedged it into a max 64k program space (for Xenix), and his upward-compatible Korn shell (ksh88) had many, many features. Then there were the "UNIX Wars"... https://en.wikipedia.org/wiki/Unix_wars https://en.wikipedia.org/wiki/Unix_wars The fallout of this was the choice of a few Korn features, but not all (no arrays, coprocesses, [some] eval, regex, et al.) The wars defined the POSIX shell. Yes, it can be infuriating.

popcube 5y ago

shell is good enough, when people started to use script language, they just wanted to fill the empty between bash and C, no one want to replace it, so bash and other shell still there

lmm 5y ago

I don't know why "we" are. Just use Python. Or whatever language you're using for your main system (I've written "scripts" in Scala, sure it takes a second or two to warm up the JVM but it's honestly fine). Or TCL if you really must have a language that can be used as a login shell.

bsder 5y ago

> Is there a reason we aren’t using a shell with a proper programming language for scripting? Mostly because the people who want to introduce a "programming language" into the shell don't prioritize being a shell. Check out the "Oh" shell for contrast. This is what a programming language looks like when you force it to conform to being a shell first priority. https://github.com/michaelmacinnis/oh https://github.com/michaelmacinnis/oh https://www.youtube.com/watch?v=v1m-WEZz46U https://www.youtube.com/watch?v=v1m-WEZz46U This is "Scheme-like" (actually the late John Shutt's Kernel-like) but has FEXPRs so things can be redefined and evaluation can be controlled.