2009/8/7 Paolo Bonzini <[email protected]>: > On 08/07/2009 01:34 PM, Reuben Thomas wrote: >> >> I hope that we still aspire to one day >> finding a POSIX shell in /bin/sh? >> Working to make /bin/sh be a POSIX shell is a much bigger win in the >> long term, so I hope that M4sh doesn't come at the expense of that. > > That's a problem with the vendors, not with "us".
As a free software user and author, I'm on both sides of this fence. But whatever system I'm working with, I try to report bugs and omissions and encourage the development and implementation of open standards. > If you stick with GNU/Linux, you can expect a bare POSIX shell (no XSI > extensions) only lacking $LINENO in /bin/sh, 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... 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 think you have a different definitions than I have for proprietary. By "proprietary" I meant "not conforming to an open standard"; that was perhaps ambiguous. > Besides, I also "encourage the use of standards whenever possible", and > would rather not have to rely on "solutions like gnulib", which are "Yet > Another Thing to learn" for portable C programs. You and I know how > realistic this is. With gnulib and autoconf, I am able to write GNU Zile almost exclusively to POSIX-1990 and C89, with some wrapper (configure.ac) and a couple of non-standard includes (e.g. where gnulib works around the brokenness of the various different basenames and dirnames). I have clean code (rather than the #ifdef-ridden style of 20 years ago) and portability is taken care of for me by the autoconf and gnulib authors. I have more problems with accidentally writing non-portable code than I do with finding problems in gnulib and autoconf. Out of about 10,000 lines of code, only about 50 are in my configure.ac or those few lines of code, and although they were disproportionately awkward lines to write, the effort involved in their maintenance is small. The key points are that a) I no longer have to write new code per system, and b) I can keep the portability code distinct from the application code. M4sh gives me a) but not b): with M4sh I have to mix M4sh macros into pure shell code. This is a pity. I admit that there's no obvious way around it other than for autotools to ship a shell (analogous to the way that by assuming only a POSIX make, automake cannot use GNU Make's extra features). To return finally to my use of the word "proprietary", whether something is a standard is not cut-and-dried. In between formal standards like POSIX and informal embedded designs like M4sh are mature, widely-documented and used systems like GNU Make and Perl. 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. 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. Are there ways to make autoconf more powerful to use that also reduce its complexity by promoting the development and deployment of standards? -- http://rrt.sc3d.org Belief marks the line at which our thinking stops (Carse)
