Re: "The `-a', `-o', `(', and `)' operands are not portable": please clarify

[Reuben Thomas]

2009/8/7 Paolo Bonzini <address@hidden>:
> 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/address@hidden/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)