3 ms·

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

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.
fipar 8y ago
I don't see how the comment is off-topic. While the HN title is "Google's bash style guide", the actual guide has the title "Shell Style Guide". To some, that reads as if a "Programming Style Guide" started by saying only C is allowed.

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.

fipar 8y ago

I don't see how the comment is off-topic. While the HN title is "Google's bash style guide", the actual guide has the title "Shell Style Guide". To some, that reads as if a "Programming Style Guide" started by saying only C is allowed.