Are you thinking of dash? As far as I can see, this has been
discussed, and there has not been a release since then (June 13,
2008):
http://www.mail-archive.com/[email protected]/msg00058.html
Maybe it's worth a ping to the dash maintainers...
Yes...
Thanks for the answers to my various questions; I'm more interested in
seeing such explanation in the manual; is there some way I can help
with this? I've recently been doing some work on autoconf-archive:
having easier-to-understand M4sh documentation would be particularly
beneficial for autoconf-archive as we try to improve the code quality,
which varies wildly and I am sure makes exceedingly dubious use of the
shell in places.
I hate to say "patches are welcome", but I have to. I'm too busy at the
moment, which is something I also hate to say because everybody is.
GNU autotools's greatest strength, its lack of assumptions about the
build environment, is the source of its greatest frustration: that as a
software author using it, one often feels stuck back in the late 1970s.
Autoconf 2.64 upgrades to the mid-eighties. Now it's younger than I am,
but still would be qualified to vote in most countries. I'd like to
define "mature standards" with a different timescale, but it's harder
than one would think. :-(
There are two ways to make progress: either, as quagmire does,
to update its dependencies; or, to ship more stuff as part of the
system. At the moment, autoconf is doing a little of the latter, as
witness M4sh, but in a way that is rather unfortunate, as although it
increases the ease of use, it also increases the amount that must be
learned to use the system, by adding to its interfaces.
Agreed, that's a problem. And ironically, the efforts to optimize
Autoconf to reduce its system time (e.g. the number of forks), are felt
even more by people using faster but less powerful shells (people say
dash is faster, though I never really experienced such a breakthrough
improvement).
On the other hand, M4sh is needed for other things than backwards
compatibility. For example, AS_IF is needed to properly order macros
that are AC_REQUIREd in an if's branch (they must be outside the if).
Paolo
