4 ms·

I think the difference is with bash & zsh is down to whether you choose to use them as your interactive shell or whether you choose to write shell scripts in th

I think the difference is with bash & zsh is down to whether you choose to use them as your interactive shell or whether you choose to write shell scripts in them. I had assumed that this was about shell script portability. Bash and zsh have a ton of super useful features to make work faster, but the features for shell programming (writing shell scripts that other people will use) are not so useful. Yes, I'm aware of stuff like [[, I don't think that [[ is very useful. I have dash as /bin/sh and #!/bin/sh in all my scripts, and seriously, it's not a problem.

forgotpwd16 5y ago
There're many features that are useful for programming: variable expansion, pattern replacement, substing expansion, and others. Not only that but some bash built-ins essentially replace external processes leading to your script being faster and more portable (ironically).
- klodolph 5y ago
  Bash is not alone in having built-ins that make it faster. Generally speaking, Bash is measurably slower than other shells. If you convert make your shell scripts portable and change #!/bin/bash to #!/bin/sh, in my experience, this usually makes them faster, too (on systems where sh is not bash). This is the driving factor for Debian's switch from Bash to Dash, which resulted in noticeable startup speed improvements: https://wiki.ubuntu.com/DashAsBinSh https://wiki.ubuntu.com/DashAsBinSh (Note that Systemd has since obviated most of that work.) You may be writing very different shell scripts than the ones which I encounter. I'm not sure what you mean by "variable expansion", because variable expansion is portable. Something like 98%+ of all pattern replacement I see is something simple like replacing a suffix or prefix of a string. For example, infile=input.png outfile="${infile%.png}.jpg" You can typically use sed for the complicated stuff. Above a certain level of complexity, I'd likely rewrite the script in Perl or Python, anyway. Or possibly Go.
  - forgotpwd16 5y ago
    For your example, in bash you can do infile=input.png outfile="${infile/.png/.jpg}" Yes, supposing it exists and you've permissions for it, you can use sed. Do that a dozen times and the calls to an external process add up to a significant time. But the real advantage is being easier to write and work with.
Cederfjard 5y ago
What level of portability do you deem necessary for what you do? I rarely encounter a box that has sh but not bash, but maybe that’s just me.
- klodolph 5y ago
  I could equally ask, "What level of Bash features do you deem necessary for what you do? I rarely encounter a shell script that cannot be trivially modified to work on POSIX /bin/sh." At least historically speaking, Bash was noticeably slower than Dash. It's the slowest shell. If you are doing things like, say, build scripts in a CI environment where you need to execute shell scripts thousands of times or more, the 4x difference can make a real impact on user experience. Same thing during startup, back before the transition to Systemd, when Debian changed the /bin/sh alias to point to Dash instead of Bash to speed up system startup. https://unix.stackexchange.com/questions/148035/is-dash-or-some-other-shell-faster-than-bash https://unix.stackexchange.com/questions/148035/is-dash-or-s... https://wiki.ubuntu.com/DashAsBinSh https://wiki.ubuntu.com/DashAsBinSh At some point, shell scripts reach a level of complexity where most people choose to rewrite them in a higher-level language, often Python or Perl, or maybe even Go. My personal experience is that the Bash-isms, although kind of nice, don't really shift that threshold... like, although Bash has arrays, but if I need to manipulate arrays, I switch to Perl or Python. If I just need to pull elements out of one array, I can do that portably.
belorn 5y ago
It seems like if one want to be a bit more focused on compatibility, just using python with compatibility added for v2 vs v3 is easier than using shell scripts for the multiple different operating system, platforms, shells and versions that exist today. Shells seems much more coupled with the operating system and decision that people have made on that level.
- klodolph 5y ago
  Yes, above a certain complexity, you'd probably want to write your script in Perl or Python. Python has an enormous overhead compared to shell scripts, though. If you're writing some simple wrapper in a build system that's going to be invoked thousands of times for a single build, Python could easily end up being a choke point. If you're really concerned about portability, I would probably write it in Perl :-) Perl is basically a souped up shell language, with built-in Awk & Sed, faster start-up time than Bash, and it's installed nearly everywhere.
  - belorn 5y ago
    Perl vs Python on the script side has always seemed to me to be a bit up to taste, through I have noticed on the sysadmin side that in general things has moved away from Perl towards Python. I also notice that in terms of job listing, there seems to be a lack of new perl programmers in order to support older systems. In terms of build systems, what I have most experience with would be with Debian and their build system, which pulls in the required dependencies. Compatibility in this space is less about zsh vs bash and more in line with architecture difference like RISC vs AMD64.
aidenn0 5y ago
Bash arrays are the only thing I really wish dash had. Some other things are "nice to have" but can be implemented on top of sh. Arrays really can't.

forgotpwd16 5y ago

There're many features that are useful for programming: variable expansion, pattern replacement, substing expansion, and others. Not only that but some bash built-ins essentially replace external processes leading to your script being faster and more portable (ironically).

klodolph 5y ago
Bash is not alone in having built-ins that make it faster. Generally speaking, Bash is measurably slower than other shells. If you convert make your shell scripts portable and change #!/bin/bash to #!/bin/sh, in my experience, this usually makes them faster, too (on systems where sh is not bash). This is the driving factor for Debian's switch from Bash to Dash, which resulted in noticeable startup speed improvements: https://wiki.ubuntu.com/DashAsBinSh https://wiki.ubuntu.com/DashAsBinSh (Note that Systemd has since obviated most of that work.) You may be writing very different shell scripts than the ones which I encounter. I'm not sure what you mean by "variable expansion", because variable expansion is portable. Something like 98%+ of all pattern replacement I see is something simple like replacing a suffix or prefix of a string. For example, infile=input.png outfile="${infile%.png}.jpg" You can typically use sed for the complicated stuff. Above a certain level of complexity, I'd likely rewrite the script in Perl or Python, anyway. Or possibly Go.
- forgotpwd16 5y ago
  For your example, in bash you can do infile=input.png outfile="${infile/.png/.jpg}" Yes, supposing it exists and you've permissions for it, you can use sed. Do that a dozen times and the calls to an external process add up to a significant time. But the real advantage is being easier to write and work with.

Cederfjard 5y ago

What level of portability do you deem necessary for what you do? I rarely encounter a box that has sh but not bash, but maybe that’s just me.

klodolph 5y ago
I could equally ask, "What level of Bash features do you deem necessary for what you do? I rarely encounter a shell script that cannot be trivially modified to work on POSIX /bin/sh." At least historically speaking, Bash was noticeably slower than Dash. It's the slowest shell. If you are doing things like, say, build scripts in a CI environment where you need to execute shell scripts thousands of times or more, the 4x difference can make a real impact on user experience. Same thing during startup, back before the transition to Systemd, when Debian changed the /bin/sh alias to point to Dash instead of Bash to speed up system startup. https://unix.stackexchange.com/questions/148035/is-dash-or-some-other-shell-faster-than-bash https://unix.stackexchange.com/questions/148035/is-dash-or-s... https://wiki.ubuntu.com/DashAsBinSh https://wiki.ubuntu.com/DashAsBinSh At some point, shell scripts reach a level of complexity where most people choose to rewrite them in a higher-level language, often Python or Perl, or maybe even Go. My personal experience is that the Bash-isms, although kind of nice, don't really shift that threshold... like, although Bash has arrays, but if I need to manipulate arrays, I switch to Perl or Python. If I just need to pull elements out of one array, I can do that portably.

belorn 5y ago

It seems like if one want to be a bit more focused on compatibility, just using python with compatibility added for v2 vs v3 is easier than using shell scripts for the multiple different operating system, platforms, shells and versions that exist today. Shells seems much more coupled with the operating system and decision that people have made on that level.

klodolph 5y ago
Yes, above a certain complexity, you'd probably want to write your script in Perl or Python. Python has an enormous overhead compared to shell scripts, though. If you're writing some simple wrapper in a build system that's going to be invoked thousands of times for a single build, Python could easily end up being a choke point. If you're really concerned about portability, I would probably write it in Perl :-) Perl is basically a souped up shell language, with built-in Awk & Sed, faster start-up time than Bash, and it's installed nearly everywhere.
- belorn 5y ago
  Perl vs Python on the script side has always seemed to me to be a bit up to taste, through I have noticed on the sysadmin side that in general things has moved away from Perl towards Python. I also notice that in terms of job listing, there seems to be a lack of new perl programmers in order to support older systems. In terms of build systems, what I have most experience with would be with Debian and their build system, which pulls in the required dependencies. Compatibility in this space is less about zsh vs bash and more in line with architecture difference like RISC vs AMD64.

aidenn0 5y ago

Bash arrays are the only thing I really wish dash had. Some other things are "nice to have" but can be implemented on top of sh. Arrays really can't.