3 ms·

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/h

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.