4 ms·

The unfortunate truth of all such projects: if it isn't pre-installed on all reasonably complete Linux distos, it can truly succeed, no matter how awesome and c

The unfortunate truth of all such projects: if it isn't pre-installed on all reasonably complete Linux distos, it can truly succeed, no matter how awesome and cool it is... ... which is why I try to write as much stuff as POSIX sh as possible, and sometimes I have to throw in a Bashism to get by. And I say this as someone that wishes sh was better, semi-lovingly.

caymanjim 5y ago
It wasn't that long ago that a fresh Unix install of any flavor didn't come with Perl, Python, zsh, or other common shell or scripting languages. And there's already a trend away from installing those by default. Since adding them now takes mere seconds, the barrier is low.
tptacek 5y ago
This isn't really true at all. We have an ungodly amount of operational process and knowledge tied up in bash scripts deployed across our fleet, but we could easily deploy a different shell, and use that. We don't use bash because it's the least common denominator on our systems --- in fact, I think in an era of AMIs and Dockerfiles, few people do. We use it because of path dependance.
- 1500100900 5y ago
  This is easy to say when you don't have to comply to some industry standards.
  - tptacek 5y ago
    I don't know what this is supposed to mean.
JNRowe 5y ago
I think part of the problem is that we still don't have a standard /bin/sh even though there is a written standard. It feels fair to me to suggest that you can call dash the working standard on Linux, but you can't trust that beyond Linux systems(and I'm ignoring installs that are busybox-based here too). And that also feels like the problem with extending a script with a few bashisms too, as you're suddenly trying to remember when that feature appeared. Off the top of my head I'm wondering what things won't be available to Mac users because it ships with a pre-GPLv3 bash for example.
- jordemort 5y ago
  Shellcheck helps a lot with this, I won't write shell without it anymore: https://www.shellcheck.net/ https://www.shellcheck.net/
  - DiabloD3 5y ago
    Here here, this has massively improved my code to the point I no longer fear sh and what horrible things I have unleashed.
  - declnz 5y ago
    Shellcheck is truly a game-changer, even for people who've been hacking Bash (etc) for 20+ years. Side note: it's also one of (or the ?) most popular Haskell projects out there: https://github.com/koalaman/shellcheck/ https://github.com/koalaman/shellcheck/
    - tym0 5y ago
      Pandoc might be more popular but I agree that Shellcheck is an absolute godsend.
- gnubison 5y ago
  > I think part of the problem is that we still don't have a standard /bin/sh even though there is a written standard. It feels fair to me to suggest that you can call dash the working standard on Linux, but you can't trust that beyond Linux systems(and I'm ignoring installs that are busybox-based here too). Why do we need a one true shell that implements the standard? Am I misunderstanding you…? The whole point of a standard is that everyone implements it so the different implementations don’t matter (and everyone does implement it, in the case of POSIX shell, minus a couple things like [ -t ] and some bash defaults).
  - JNRowe 5y ago
    Given developers testing against shells that implement the spec, and a solid spec, and a variety of implementations that correctly implement that spec then I'm in full agreement with you. However, the moment you add caveats to that description you have, well… caveats to that description. The situation - as I see it - is that we have a spec, and we have systems that ship a /bin/sh that implements something like it. If people are targetting their system's /bin/sh, then they're writing scripts for their /bin/sh implementation not posix compliant shells. For example, my install uses dash which has features beyond the posix spec which I have to eschew to produce portable scripts. As a sibling comment points out shellcheck will point out a lot problems, but it requires people choosing to use it. You only have to dive around /usr/bin for a little while to see its usage isn't universal ;) Of course, if the differences in implementation don't affect your usecase then it simply doesn't matter.
colordrops 5y ago
How often do you run into an issue where things only would have worked if you use sh? What domain are you working in?
CobrastanJorji 5y ago
I dunno, I think the future of interesting shell scripting languages can either be a.) the basis for a new distro, which will decide to use it for the system scripts, b.) be intended for use with containers in some manner and can simply be added as another dependency, or c.) be primarily intended to be used interactively in some unique way, so it'll just be installed by individuals. There will always be a place for the universal shells and text editors. Bash and vim aren't going away any time soon. But there are plenty of places for non-default choices. Vim's existence doesn't mean Sublime doesn't have a place.

caymanjim 5y ago

It wasn't that long ago that a fresh Unix install of any flavor didn't come with Perl, Python, zsh, or other common shell or scripting languages. And there's already a trend away from installing those by default. Since adding them now takes mere seconds, the barrier is low.

tptacek 5y ago

This isn't really true at all. We have an ungodly amount of operational process and knowledge tied up in bash scripts deployed across our fleet, but we could easily deploy a different shell, and use that. We don't use bash because it's the least common denominator on our systems --- in fact, I think in an era of AMIs and Dockerfiles, few people do. We use it because of path dependance.

1500100900 5y ago
This is easy to say when you don't have to comply to some industry standards.
- tptacek 5y ago
  I don't know what this is supposed to mean.

JNRowe 5y ago

I think part of the problem is that we still don't have a standard /bin/sh even though there is a written standard. It feels fair to me to suggest that you can call dash the working standard on Linux, but you can't trust that beyond Linux systems(and I'm ignoring installs that are busybox-based here too). And that also feels like the problem with extending a script with a few bashisms too, as you're suddenly trying to remember when that feature appeared. Off the top of my head I'm wondering what things won't be available to Mac users because it ships with a pre-GPLv3 bash for example.

jordemort 5y ago
Shellcheck helps a lot with this, I won't write shell without it anymore: https://www.shellcheck.net/ https://www.shellcheck.net/
- DiabloD3 5y ago
  Here here, this has massively improved my code to the point I no longer fear sh and what horrible things I have unleashed.
- declnz 5y ago
  Shellcheck is truly a game-changer, even for people who've been hacking Bash (etc) for 20+ years. Side note: it's also one of (or the ?) most popular Haskell projects out there: https://github.com/koalaman/shellcheck/ https://github.com/koalaman/shellcheck/
  - tym0 5y ago
    Pandoc might be more popular but I agree that Shellcheck is an absolute godsend.
gnubison 5y ago
> I think part of the problem is that we still don't have a standard /bin/sh even though there is a written standard. It feels fair to me to suggest that you can call dash the working standard on Linux, but you can't trust that beyond Linux systems(and I'm ignoring installs that are busybox-based here too). Why do we need a one true shell that implements the standard? Am I misunderstanding you…? The whole point of a standard is that everyone implements it so the different implementations don’t matter (and everyone does implement it, in the case of POSIX shell, minus a couple things like [ -t ] and some bash defaults).
- JNRowe 5y ago
  Given developers testing against shells that implement the spec, and a solid spec, and a variety of implementations that correctly implement that spec then I'm in full agreement with you. However, the moment you add caveats to that description you have, well… caveats to that description. The situation - as I see it - is that we have a spec, and we have systems that ship a /bin/sh that implements something like it. If people are targetting their system's /bin/sh, then they're writing scripts for their /bin/sh implementation not posix compliant shells. For example, my install uses dash which has features beyond the posix spec which I have to eschew to produce portable scripts. As a sibling comment points out shellcheck will point out a lot problems, but it requires people choosing to use it. You only have to dive around /usr/bin for a little while to see its usage isn't universal ;) Of course, if the differences in implementation don't affect your usecase then it simply doesn't matter.

colordrops 5y ago

How often do you run into an issue where things only would have worked if you use sh? What domain are you working in?

CobrastanJorji 5y ago

I dunno, I think the future of interesting shell scripting languages can either be a.) the basis for a new distro, which will decide to use it for the system scripts, b.) be intended for use with containers in some manner and can simply be added as another dependency, or c.) be primarily intended to be used interactively in some unique way, so it'll just be installed by individuals. There will always be a place for the universal shells and text editors. Bash and vim aren't going away any time soon. But there are plenty of places for non-default choices. Vim's existence doesn't mean Sublime doesn't have a place.