10 ms·

>Bash is the only shell scripting language permitted for executables. Whelp, wrong right off the bat. I'm gonna get down my my knees here and beg everyone rea

>Bash is the only shell scripting language permitted for executables. Whelp, wrong right off the bat. I'm gonna get down my my knees here and beg everyone reading: use POSIX shell. Do not write scripts with bash. Do not write scripts with zsh. Do not write scripts with fish. Use POSIX shell. sh has a really bad interactive mode (so does bash), so I'm not gonna give anyone a hard time for using another shell as their day-to-day interactive shell. But, for the love of god, write your scripts with POSIX sh.

jon-wood 8y ago
I'm genuinely curious, why? If you're writing generic scripts designed to run across multiple platforms then fine, but in the context of Google (or most other companies) they'll have a standard set of tooling available on all their machines, which presumably includes Bash if they're making that statement. What about POSIX shell makes it superior for scripting?
- JepZ 8y ago
  Maybe one day there will be another cool and dominating shell. That shell is more likely to be POSIX compliant than bash compliant.
  - deleted 8y ago
    [deleted]
  - oblio 8y ago
    All the cool new shells I've seen are either completely POSIX incompatible (powershell, xonsh, etc.) or they try to be bash supersets (zsh, osh, etc.). Bash is a de facto modern standard. The only new purely POSIX shells I know are for embedded stuff (dash) and that space is neither fast moving nor in dire need of a better shell, since most modern shell features target interactive use. Or they make coding easier and/or safer, in which case we're back to point 1, with the POSIX incompatibility.
    - JepZ 8y ago
      Maybe the missing POSIX compatibility is the reason why they haven't replaced bash yet.
      - oblio 8y ago
        Nothing will replace bash within my lifetime. Zsh didn't even though it was superior for over a decade. Heck, Microsoft barely managed to supplant cmd 1-2 years ago, and that's in a non-standard, proprietary environment by what is arguably the biggest commercial platform maker in the world.
- Sir_Cmpwn 8y ago
  Google also makes it difficult to compile Chromium on platforms where /usr/bin/python is python 3, because their shebangs are: #!/usr/bin/env python Rather than the more portable: #!/usr/bin/env python3 Notably this causes problems for people on Arch Linux, and in the near future, Fedora. This post is presented as a style guide that others should adopt. Google may have bash ubiquiotously available internally, but their approach should not be taken as a model for others. Google's approach has caused real problems for their software's portability in exchange for dubious value-adds. >What about POSIX shell makes it superior for scripting? To address this specifically, I have written a blog article on the subject: https://drewdevault.com/2018/02/05/Introduction-to-POSIX-shell.html https://drewdevault.com/2018/02/05/Introduction-to-POSIX-she... The main points are: - bash is far from as ubiquitous as some people seem to think it is - sh is formally standardized and has multiple competing implementations, whereas bash is defined by its implementation and there is only one - sh is perfectly competent and easy to target, bash's value add is questionable - By the time you need the things bash offers you might as well not use a shell script at all
  - marcoperaza 8y ago
    Competing implementations sounds like a potential downside to me. That’s just more possible configurations where a bug could be hiding. Even if you use standard posix shell, you’d be wise to target a single implementation and stick to it.
    - Sir_Cmpwn 8y ago
      So you think that competition between gcc and clang is harmful to the C and C++ ecosystems? If you find bugs in an implementation of POSIX sh, you should report it to that implementation. Multiple competing implementations is a sign of a good standard, it proves the standard's correctness and demonstrates its maturity. There is no standard to hold bash to. Any strange behavior of it might be decided as by design and kept forever (and replicated by anything which tries to be bash compatible) or it could be determined to be a bug and, when fixed, break the scripts which worked around it or depended on it. There's no way to know how this is going to shake out because there is no objective specification for the language. At least when there's a bug in one of these competing sh implementations that you're so worried about, it's objectively a bug and can be fixed.
- simias 8y ago
  I don't feel as strongly about it as Sir_Cmpwn does but I agree with him. The logic goes something like: you should only use shell scripts for small scripts and not complex applications. Ergo the added functionality of bash scripts should not be necessary anyway and might actually lead you to believe that it's a proper programming language. Or to put it the other way around: if you find yourself writing a POSIX shell script and find that you'd like to use more advanced features then one of two things can happen: - You need portability to SunOS 4, so you suck it up and keep hacking your script because bash is not an option anyway; - You don't need portability, so then why not use a proper programming language like python, perl or ruby rather than upgrading from crappy sh to slightly-less-crappy bash?
  - avar 8y ago
    This logic is insane. This is like a company that mainly does C++ or Java saying that if you must use a scripting language it must be Tcl, not Perl or Python, least you get too comfortable with it. If you want a policy against shellscripts growing out of hand have a policy against that, not that you must use the lowest common denominator even though you have Bash everywhere. And I'm saying this as someone who almost exclusively writes POSIX sh for portability reasons, but my software isn't meant to target just Google's infra.
    - simias 8y ago
      I think it would be perfectly sane for a company to dictate which scripting language their environment will support. Shell scripts are a bit different though because if you write a large enough software system on a unix-like OS you'll probably want to write a few shell scripts here and there to glue things together, so forbidding them completely would be a bit silly and counterproductive. Saying "avoid shell scripts, if you really have to write one it must be simple and use POSIX sh" is not particularly insane to me. But anyway my argument was more about my opinion about a developer talking for myself, not a company style guide. Life's too short to learn two shell dialects so I can either learn POSIX which will work basically everywhere and will let me write any simple script just fine or write Bash whose added complexity I probably won't need or even want. The fact that I'm an embedded dev probably biases my view though, I generally target environments where bash isn't an option anyway.
- nurettin 8y ago
  Probably because he can't use bash code in his BusyBox based router
  - pas 8y ago
    And what's the magically amazing script that anyone would like to run on routers and AIXes alike, that it has to be POSIX portable? :)
bnferguson 8y ago
You're getting voted down (likely for only saying the article is wrong but not why), but I'm curious your reasoning. I've tended to write in POSIX sh (for maximum compatibility - and because it was just the way I learned) - but am happy to use bash too when the project allows and it makes sense so not sure I get the hard line stance. Wondering what I might be missing to evoke such a response.
- Sir_Cmpwn 8y ago
  I wrote in some greater detail in response to someone else: https://news.ycombinator.com/item?id=17073703 https://news.ycombinator.com/item?id=17073703
marcoperaza 8y ago
Portability doesn’t make sense for an operation like Google. Even if some new shell promises compatibility, you still have to test every single script against it. Why bother? Write scripts in bash, run them in bash. In the future, switch to whatever you want for new scripts.
thankthunk 8y ago
> Do not write scripts with bash. It's a bit too late for that. Bash is pretty much the de facto default shell for linux. Telling people not to use bash scripts is like telling web devs not to use javascript or OS devs not to use C. It may change in the future, but bash is so entrenched, it's going to take an extraordinary use case for people to move from bash.
- Sir_Cmpwn 8y ago
  >Telling people not to use bash scripts is like telling web devs not to use javascript or OS devs not to use C. Wow, this comparison is totally whack. Javascript and C are both standardized and the former is the only option when using a web browser. It's never too late. We managed to get people off of ANSI C and there's a similar amount of difference between ANSI* C and C89 as there is between bash and sh. * correction: pre-ANSI
  - thankthunk 8y ago
    > Wow, this comparison is totally whack Did you really say whack? > Javascript and C are both standardized and the former is the only option when using a web browser. Javascript isn't the only option. It is the most popular by far and hence the "de facto" language of the web. And javascript certainly isn't "standardized" in the sense you are writing. Do you know anything about web development, browser implementation of javascript and javascript itself? Javascript is no more "standardized" than SQL is standardized. Every RDBMs implements their own flavor of SQL just like browsers do with javascript. >It's never too late. Did I say it was too late? Of course I didn't. Maybe if you took a step back from your fanboyism and read... "It may change in the future, but bash is so entrenched, it's going to take an extraordinary use case for people to move from bash." > We managed to get people off of ANSI C and there's a similar amount of difference between ANSI C and C89 as there is between bash and sh. ANSI C and C89 are the same thing. ANSI C is just another name for C89... Sigh...
    - Sir_Cmpwn 8y ago
      >Javascript isn't the only option. It is the most popular by far and hence the "de facto" language of the web. And javascript certainly isn't "standardized" in the sense you are writing. Do you know anything about web development, browser implementation of javascript and javascript itself? Javascript is no more "standardized" than SQL is standardized. Every RDBMs implements their own flavor of SQL just like browsers do with javascript. This is nonsense. I am very familiar with web browsers. Javascript is standardized as ECMAScript: https://www.ecma-international.org/publications/standards/Ecma-262.htm https://www.ecma-international.org/publications/standards/Ec... The "standard library" browsers implement is also standardized: https://www.w3.org/standards/ https://www.w3.org/standards/ You're off your rocker. >Did I say it was too late? Of course I didn't. Maybe if you took a step back from your fanboyism and read... Here is a direct quote from your comment: >It's a bit too late for that. Bash is pretty much the de facto default shell for linux. >ANSI C and C89 are the same thing. ANSI C is just another name for C89... Sigh... Derp, I meant K&R C or pre-ANSI C. My mistake.
reacweb 8y ago
I have the opposite opinion. I have seen developers proudly putting /bin/sh instead of /bin/bash, without any other shell to test. When the script was run on ubuntu instead of redhat, this called dash and we discovered that the script was finally not compliant on subtle details. Writing POSIX compliant scripts is harder. Where is the reward when bash is present (almost) everywhere?
- Sir_Cmpwn 8y ago
  >Where is the reward when bash is present (almost) everywhere? It's really not. It's only present on some desktop Linux distributions. It's not present on almost any other OS or anywhere in the embedded space. POSIX shell, on the other hand, is everywhere.
  - susam 8y ago
    > POSIX shell, on the other hand, is everywhere. Indeed! The significance of this, I believe, is underappreciated. During 2008-2015, when I used to work for a network security company, we had a file transfer script[1] for Unix and Linux systems. It was written entirely as a shell script. It began as a simple wrapper around the scp and sftp commands for which a shell script was appropriate. The fact that every Unix and Linux system comes with a shell meant that we could ship a single file to all target Unix and Linux systems without requiring the administrator to install any new packages. The alternative was writing the file transfer functionality in C or C++ which would have required us to build and test the solution for every possible Unix system that our customers used or writing it in Java which would have required us to require the customer to install JVM on their systems. Many customer admins were averse to installing any additional packages on their systems. Given these constraints, a shell script was a good solution. Unfortunately, the initial shell script relied on several bashisms.[2] Some customers began complaining that their Solaris or AIX system did not have bash, and they needed the script to work with Bourne shell or Korn shell. The customers refused to install bash. So I decided to clean up the script, remove all bashisms from it, and ensure that only POSIX specified features were used, only POSIX specified commands were invoked with POSIX specified options only (with the exception of the scp and sftp commands of course because that was the primary reason why the customers wanted the script). I am not fond of bashisms. If I need bashims like arrays or regex substitutions in parameter expansions, it's a sign that the script is becoming complex and I switch to a modern programming language. These days, when I write a shell script[3], I restrict myself to POSIX.2001 (2004 edition)[4], write unit tests to exercise every line of code, run the unit tests with bash, ksh, zsh, dash, posh, and yash on Debian, run the tests with bash, ksh, and zsh on macOS, and use Kcov[5] to measure test coverage. [1]: https://community.rsa.com/docs/DOC-53124 https://community.rsa.com/docs/DOC-53124 [2]: https://mywiki.wooledge.org/Bashism https://mywiki.wooledge.org/Bashism [3]: https://github.com/susam/vimer https://github.com/susam/vimer [4]: http://pubs.opengroup.org/onlinepubs/009695399/ http://pubs.opengroup.org/onlinepubs/009695399/ [5]: https://github.com/SimonKagstrom/kcov https://github.com/SimonKagstrom/kcov
moviuro 8y ago
> >Bash is the only shell scripting language permitted for executables. > Whelp, wrong right off the bat. It really is a Google guide, tailored to Google engineers. If they know for sure that bash is available on any *n?x machine, then why not? It's just a local policy. And if it's that much of a problem, the other places where you get bash instead of POSIX sh from Google (chromium?) the license clearly allows you to rewrite said script to suit your needs. All other points are valid though. Note that I chose to write all my scripts in POSIX (e.g. https://gitlab.com/moviuro/moviuro.bin https://gitlab.com/moviuro/moviuro.bin).
- Sir_Cmpwn 8y ago
  >It really is a Google guide, tailored to Google engineers. And posted in a public forum, which is why I made sure to protest its adoption by the broader public.
  - alecbenzer 8y ago
    I don't get that from "Whelp, wrong off the bat", which seems to imply that there is a more unambiguous right answer here, and Google is wrong for deviating from it.
    - Sir_Cmpwn 8y ago
      Well, even within Google I think this policy is stupid. Any software they make open source or have to port to new platforms that was based on this policy is going to break, and for what? Bashisms provide a dubious value-add.
pc86 8y ago
None of this rant actually says why we should use POSIX shell over anything else though.
anothergoogler 8y ago
Truly portable shell scripts cannot define functions. Have you ever seen autotools' output? No thanks, I'll be impure and wrong and get the job done. Also your comment is off-topic... not sure why you see every thread about Bash as the right place to start this pedantic flameskirmish.
- Sir_Cmpwn 8y ago
  Of course portable shell scripts can define functions. What are you talking about? Shell functions are defined in POSIX. Maybe you should consult the standard before you proceed: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3...
  - anothergoogler 8y ago
    I'm technically wrong per POSIX but practically right per your principle motivation of portability: https://www.gnu.org/software/autoconf/manual/autoconf-2.66/html_node/Shell-Script-Compiler.html https://www.gnu.org/software/autoconf/manual/autoconf-2.66/h... > Unfortunately, even in 2008, where shells without any function support are far and few between, there are pitfalls to avoid when making use of them. Also, finding a Bourne shell that accepts shell functions is not trivial, even though there is almost always one on interesting porting targets.
    - Sir_Cmpwn 8y ago
      This document is 10 years old, and even then it acknowledged that finding shells without function support is a tough ask. You're not practically right, either. When a system does not (correctly) implement portable standards, it is a bug in the system and software should not be corrected to accomodate for it. autotools disagrees with me on this point.
      - anothergoogler 8y ago
        Yea, I'm going to side with autotools' maintainers on matters of software portability. And because I'm not aiming for autotools-levels of portability, I just write v3-compatible Bash, to help out my GPL2 OSX friends.
raverbashing 8y ago
Nobody cares about non-bash shells if they're not dealing with legacy systems. (And if you are, you have bigger problems)
- Sir_Cmpwn 8y ago
  Wrong. *BSD are not legacy systems, and many Linux installs don't have Bash. On top of that, new systems can't really implement Bash (because bash is defined by the implementation) but could easily implement POSIX sh (because POSIX sh is defined by the standard).
  - raverbashing 8y ago
    Agreed with BSD, but they usually have bash. (And you usually can compile it for your legacy application - I have done this) Though I agree that if you're doing something bash specific you're most likely doing something that would be done better using Python/Perl/Ruby, etc
    - gkya 8y ago
      Default *BSD installs do not have bash, it needs to be installed (IDK what DragonFly and TrueOS do, but FreeBSD, NetBSD and OpenBSD don't ship with it). They all have it in the ports trees though. Many distros use BusyBox (IIRC Alpine is one). And AFAIK Debian base only has dash at /bin/sh. Preferably the complexity in a shell script should be mostly handled by the programs invoked in it. All it has to provide is variables, basic control flow, subshells, and maybe some globbing.
peterwwillis 8y ago
Only if you need portability. If you don't need portability, write it in whatever you want. I prefer bash because it's everywhere. Zsh is too esoteric for me, but I wouldn't judge anyone for using it.

jon-wood 8y ago

I'm genuinely curious, why? If you're writing generic scripts designed to run across multiple platforms then fine, but in the context of Google (or most other companies) they'll have a standard set of tooling available on all their machines, which presumably includes Bash if they're making that statement. What about POSIX shell makes it superior for scripting?

JepZ 8y ago
Maybe one day there will be another cool and dominating shell. That shell is more likely to be POSIX compliant than bash compliant.
- deleted 8y ago
  [deleted]
- oblio 8y ago
  All the cool new shells I've seen are either completely POSIX incompatible (powershell, xonsh, etc.) or they try to be bash supersets (zsh, osh, etc.). Bash is a de facto modern standard. The only new purely POSIX shells I know are for embedded stuff (dash) and that space is neither fast moving nor in dire need of a better shell, since most modern shell features target interactive use. Or they make coding easier and/or safer, in which case we're back to point 1, with the POSIX incompatibility.
  - JepZ 8y ago
    Maybe the missing POSIX compatibility is the reason why they haven't replaced bash yet.
    - oblio 8y ago
      Nothing will replace bash within my lifetime. Zsh didn't even though it was superior for over a decade. Heck, Microsoft barely managed to supplant cmd 1-2 years ago, and that's in a non-standard, proprietary environment by what is arguably the biggest commercial platform maker in the world.
Sir_Cmpwn 8y ago
Google also makes it difficult to compile Chromium on platforms where /usr/bin/python is python 3, because their shebangs are: #!/usr/bin/env python Rather than the more portable: #!/usr/bin/env python3 Notably this causes problems for people on Arch Linux, and in the near future, Fedora. This post is presented as a style guide that others should adopt. Google may have bash ubiquiotously available internally, but their approach should not be taken as a model for others. Google's approach has caused real problems for their software's portability in exchange for dubious value-adds. >What about POSIX shell makes it superior for scripting? To address this specifically, I have written a blog article on the subject: https://drewdevault.com/2018/02/05/Introduction-to-POSIX-shell.html https://drewdevault.com/2018/02/05/Introduction-to-POSIX-she... The main points are: - bash is far from as ubiquitous as some people seem to think it is - sh is formally standardized and has multiple competing implementations, whereas bash is defined by its implementation and there is only one - sh is perfectly competent and easy to target, bash's value add is questionable - By the time you need the things bash offers you might as well not use a shell script at all
- marcoperaza 8y ago
  Competing implementations sounds like a potential downside to me. That’s just more possible configurations where a bug could be hiding. Even if you use standard posix shell, you’d be wise to target a single implementation and stick to it.
  - Sir_Cmpwn 8y ago
    So you think that competition between gcc and clang is harmful to the C and C++ ecosystems? If you find bugs in an implementation of POSIX sh, you should report it to that implementation. Multiple competing implementations is a sign of a good standard, it proves the standard's correctness and demonstrates its maturity. There is no standard to hold bash to. Any strange behavior of it might be decided as by design and kept forever (and replicated by anything which tries to be bash compatible) or it could be determined to be a bug and, when fixed, break the scripts which worked around it or depended on it. There's no way to know how this is going to shake out because there is no objective specification for the language. At least when there's a bug in one of these competing sh implementations that you're so worried about, it's objectively a bug and can be fixed.
simias 8y ago
I don't feel as strongly about it as Sir_Cmpwn does but I agree with him. The logic goes something like: you should only use shell scripts for small scripts and not complex applications. Ergo the added functionality of bash scripts should not be necessary anyway and might actually lead you to believe that it's a proper programming language. Or to put it the other way around: if you find yourself writing a POSIX shell script and find that you'd like to use more advanced features then one of two things can happen: - You need portability to SunOS 4, so you suck it up and keep hacking your script because bash is not an option anyway; - You don't need portability, so then why not use a proper programming language like python, perl or ruby rather than upgrading from crappy sh to slightly-less-crappy bash?
- avar 8y ago
  This logic is insane. This is like a company that mainly does C++ or Java saying that if you must use a scripting language it must be Tcl, not Perl or Python, least you get too comfortable with it. If you want a policy against shellscripts growing out of hand have a policy against that, not that you must use the lowest common denominator even though you have Bash everywhere. And I'm saying this as someone who almost exclusively writes POSIX sh for portability reasons, but my software isn't meant to target just Google's infra.
  - simias 8y ago
    I think it would be perfectly sane for a company to dictate which scripting language their environment will support. Shell scripts are a bit different though because if you write a large enough software system on a unix-like OS you'll probably want to write a few shell scripts here and there to glue things together, so forbidding them completely would be a bit silly and counterproductive. Saying "avoid shell scripts, if you really have to write one it must be simple and use POSIX sh" is not particularly insane to me. But anyway my argument was more about my opinion about a developer talking for myself, not a company style guide. Life's too short to learn two shell dialects so I can either learn POSIX which will work basically everywhere and will let me write any simple script just fine or write Bash whose added complexity I probably won't need or even want. The fact that I'm an embedded dev probably biases my view though, I generally target environments where bash isn't an option anyway.
nurettin 8y ago
Probably because he can't use bash code in his BusyBox based router
- pas 8y ago
  And what's the magically amazing script that anyone would like to run on routers and AIXes alike, that it has to be POSIX portable? :)

bnferguson 8y ago

You're getting voted down (likely for only saying the article is wrong but not why), but I'm curious your reasoning. I've tended to write in POSIX sh (for maximum compatibility - and because it was just the way I learned) - but am happy to use bash too when the project allows and it makes sense so not sure I get the hard line stance. Wondering what I might be missing to evoke such a response.

Sir_Cmpwn 8y ago
I wrote in some greater detail in response to someone else: https://news.ycombinator.com/item?id=17073703 https://news.ycombinator.com/item?id=17073703

marcoperaza 8y ago

Portability doesn’t make sense for an operation like Google. Even if some new shell promises compatibility, you still have to test every single script against it. Why bother? Write scripts in bash, run them in bash. In the future, switch to whatever you want for new scripts.

thankthunk 8y ago

> Do not write scripts with bash. It's a bit too late for that. Bash is pretty much the de facto default shell for linux. Telling people not to use bash scripts is like telling web devs not to use javascript or OS devs not to use C. It may change in the future, but bash is so entrenched, it's going to take an extraordinary use case for people to move from bash.

Sir_Cmpwn 8y ago
>Telling people not to use bash scripts is like telling web devs not to use javascript or OS devs not to use C. Wow, this comparison is totally whack. Javascript and C are both standardized and the former is the only option when using a web browser. It's never too late. We managed to get people off of ANSI C and there's a similar amount of difference between ANSI* C and C89 as there is between bash and sh. * correction: pre-ANSI
- thankthunk 8y ago
  > Wow, this comparison is totally whack Did you really say whack? > Javascript and C are both standardized and the former is the only option when using a web browser. Javascript isn't the only option. It is the most popular by far and hence the "de facto" language of the web. And javascript certainly isn't "standardized" in the sense you are writing. Do you know anything about web development, browser implementation of javascript and javascript itself? Javascript is no more "standardized" than SQL is standardized. Every RDBMs implements their own flavor of SQL just like browsers do with javascript. >It's never too late. Did I say it was too late? Of course I didn't. Maybe if you took a step back from your fanboyism and read... "It may change in the future, but bash is so entrenched, it's going to take an extraordinary use case for people to move from bash." > We managed to get people off of ANSI C and there's a similar amount of difference between ANSI C and C89 as there is between bash and sh. ANSI C and C89 are the same thing. ANSI C is just another name for C89... Sigh...
  - Sir_Cmpwn 8y ago
    >Javascript isn't the only option. It is the most popular by far and hence the "de facto" language of the web. And javascript certainly isn't "standardized" in the sense you are writing. Do you know anything about web development, browser implementation of javascript and javascript itself? Javascript is no more "standardized" than SQL is standardized. Every RDBMs implements their own flavor of SQL just like browsers do with javascript. This is nonsense. I am very familiar with web browsers. Javascript is standardized as ECMAScript: https://www.ecma-international.org/publications/standards/Ecma-262.htm https://www.ecma-international.org/publications/standards/Ec... The "standard library" browsers implement is also standardized: https://www.w3.org/standards/ https://www.w3.org/standards/ You're off your rocker. >Did I say it was too late? Of course I didn't. Maybe if you took a step back from your fanboyism and read... Here is a direct quote from your comment: >It's a bit too late for that. Bash is pretty much the de facto default shell for linux. >ANSI C and C89 are the same thing. ANSI C is just another name for C89... Sigh... Derp, I meant K&R C or pre-ANSI C. My mistake.

reacweb 8y ago

I have the opposite opinion. I have seen developers proudly putting /bin/sh instead of /bin/bash, without any other shell to test. When the script was run on ubuntu instead of redhat, this called dash and we discovered that the script was finally not compliant on subtle details. Writing POSIX compliant scripts is harder. Where is the reward when bash is present (almost) everywhere?

Sir_Cmpwn 8y ago
>Where is the reward when bash is present (almost) everywhere? It's really not. It's only present on some desktop Linux distributions. It's not present on almost any other OS or anywhere in the embedded space. POSIX shell, on the other hand, is everywhere.
- susam 8y ago
  > POSIX shell, on the other hand, is everywhere. Indeed! The significance of this, I believe, is underappreciated. During 2008-2015, when I used to work for a network security company, we had a file transfer script[1] for Unix and Linux systems. It was written entirely as a shell script. It began as a simple wrapper around the scp and sftp commands for which a shell script was appropriate. The fact that every Unix and Linux system comes with a shell meant that we could ship a single file to all target Unix and Linux systems without requiring the administrator to install any new packages. The alternative was writing the file transfer functionality in C or C++ which would have required us to build and test the solution for every possible Unix system that our customers used or writing it in Java which would have required us to require the customer to install JVM on their systems. Many customer admins were averse to installing any additional packages on their systems. Given these constraints, a shell script was a good solution. Unfortunately, the initial shell script relied on several bashisms.[2] Some customers began complaining that their Solaris or AIX system did not have bash, and they needed the script to work with Bourne shell or Korn shell. The customers refused to install bash. So I decided to clean up the script, remove all bashisms from it, and ensure that only POSIX specified features were used, only POSIX specified commands were invoked with POSIX specified options only (with the exception of the scp and sftp commands of course because that was the primary reason why the customers wanted the script). I am not fond of bashisms. If I need bashims like arrays or regex substitutions in parameter expansions, it's a sign that the script is becoming complex and I switch to a modern programming language. These days, when I write a shell script[3], I restrict myself to POSIX.2001 (2004 edition)[4], write unit tests to exercise every line of code, run the unit tests with bash, ksh, zsh, dash, posh, and yash on Debian, run the tests with bash, ksh, and zsh on macOS, and use Kcov[5] to measure test coverage. [1]: https://community.rsa.com/docs/DOC-53124 https://community.rsa.com/docs/DOC-53124 [2]: https://mywiki.wooledge.org/Bashism https://mywiki.wooledge.org/Bashism [3]: https://github.com/susam/vimer https://github.com/susam/vimer [4]: http://pubs.opengroup.org/onlinepubs/009695399/ http://pubs.opengroup.org/onlinepubs/009695399/ [5]: https://github.com/SimonKagstrom/kcov https://github.com/SimonKagstrom/kcov

moviuro 8y ago

> >Bash is the only shell scripting language permitted for executables. > Whelp, wrong right off the bat. It really is a Google guide, tailored to Google engineers. If they know for sure that bash is available on any *n?x machine, then why not? It's just a local policy. And if it's that much of a problem, the other places where you get bash instead of POSIX sh from Google (chromium?) the license clearly allows you to rewrite said script to suit your needs. All other points are valid though. Note that I chose to write all my scripts in POSIX (e.g. https://gitlab.com/moviuro/moviuro.bin https://gitlab.com/moviuro/moviuro.bin).

Sir_Cmpwn 8y ago
>It really is a Google guide, tailored to Google engineers. And posted in a public forum, which is why I made sure to protest its adoption by the broader public.
- alecbenzer 8y ago
  I don't get that from "Whelp, wrong off the bat", which seems to imply that there is a more unambiguous right answer here, and Google is wrong for deviating from it.
  - Sir_Cmpwn 8y ago
    Well, even within Google I think this policy is stupid. Any software they make open source or have to port to new platforms that was based on this policy is going to break, and for what? Bashisms provide a dubious value-add.

pc86 8y ago

None of this rant actually says why we should use POSIX shell over anything else though.

anothergoogler 8y ago

Truly portable shell scripts cannot define functions. Have you ever seen autotools' output? No thanks, I'll be impure and wrong and get the job done. Also your comment is off-topic... not sure why you see every thread about Bash as the right place to start this pedantic flameskirmish.

Sir_Cmpwn 8y ago
Of course portable shell scripts can define functions. What are you talking about? Shell functions are defined in POSIX. Maybe you should consult the standard before you proceed: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3...
- anothergoogler 8y ago
  I'm technically wrong per POSIX but practically right per your principle motivation of portability: https://www.gnu.org/software/autoconf/manual/autoconf-2.66/html_node/Shell-Script-Compiler.html https://www.gnu.org/software/autoconf/manual/autoconf-2.66/h... > Unfortunately, even in 2008, where shells without any function support are far and few between, there are pitfalls to avoid when making use of them. Also, finding a Bourne shell that accepts shell functions is not trivial, even though there is almost always one on interesting porting targets.
  - Sir_Cmpwn 8y ago
    This document is 10 years old, and even then it acknowledged that finding shells without function support is a tough ask. You're not practically right, either. When a system does not (correctly) implement portable standards, it is a bug in the system and software should not be corrected to accomodate for it. autotools disagrees with me on this point.
    - anothergoogler 8y ago
      Yea, I'm going to side with autotools' maintainers on matters of software portability. And because I'm not aiming for autotools-levels of portability, I just write v3-compatible Bash, to help out my GPL2 OSX friends.

raverbashing 8y ago

Nobody cares about non-bash shells if they're not dealing with legacy systems. (And if you are, you have bigger problems)

Sir_Cmpwn 8y ago
Wrong. *BSD are not legacy systems, and many Linux installs don't have Bash. On top of that, new systems can't really implement Bash (because bash is defined by the implementation) but could easily implement POSIX sh (because POSIX sh is defined by the standard).
- raverbashing 8y ago
  Agreed with BSD, but they usually have bash. (And you usually can compile it for your legacy application - I have done this) Though I agree that if you're doing something bash specific you're most likely doing something that would be done better using Python/Perl/Ruby, etc
  - gkya 8y ago
    Default *BSD installs do not have bash, it needs to be installed (IDK what DragonFly and TrueOS do, but FreeBSD, NetBSD and OpenBSD don't ship with it). They all have it in the ports trees though. Many distros use BusyBox (IIRC Alpine is one). And AFAIK Debian base only has dash at /bin/sh. Preferably the complexity in a shell script should be mostly handled by the programs invoked in it. All it has to provide is variables, basic control flow, subshells, and maybe some globbing.

peterwwillis 8y ago

Only if you need portability. If you don't need portability, write it in whatever you want. I prefer bash because it's everywhere. Zsh is too esoteric for me, but I wouldn't judge anyone for using it.