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

[Paolo Bonzini]

On 08/07/2009 01:34 PM, Reuben Thomas wrote:
> 2009/8/7 Paolo Bonzini<address@hidden>:
> > If you write a script with
> >
> > #! /bin/sh
> >
> > then yes, you cannot program to _any_ standard.
>
> That's pretty pessimistic then.

It is.

> 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".

If you stick with GNU/Linux, you can expect a bare POSIX shell (no XSI 
extensions) only lacking $LINENO in /bin/sh, and you can expect 
/bin/bash is there too except on very small, mostly BusyBox-based file 
systems.

> So does that mean that shell code written in autoconf should use M4sh
> now? The documentation for M4sh is a bit unclear on matters like
> exactly what features one can rely on without needing M4sh

Anything not using M4sh should follow "Limitations of shell builtins" 
(which also hints at solutions using M4sh whenever useful).

> and which features would need M4sh support but don't yet have it.

Maybe some more ${} expansions like ${a%b} and ${a#b}.  Besides this, I 
cannot think of others.

> In short, it's
> not clear what the language is that one is writing in when using M4sh.
> Does one have to call AS_INIT in configure.ac before using other M4sh
> functions?

All configure.ac files are M4sh scripts too; AS_INIT is called in all 
configure scripts automatically (and in config.status too).

> AS_INIT's documentation is a bit odd, because AS_INIT
> doesn't provide a portable version of a shell function

AS_INIT ensures that you can define shell functions normally using

  foo () {
    # body
  }

Alternatively, there is AS_REQUIRE_SHELL_FN that provides a way to 
define shell functions from within a m4 macro, ensuring that it will be 
defined only once and in the proper place in the resulting shell script.

> , whereas most
> of the other macros documented do. Similarly, it's unclear what the
> use of AS_BOURNE_COMPATIBLE is: what does "more compatible" mean? Why
> isn't it always implied in AS_INIT?&c.

It is implied in AS_INIT.  It is a subset for when you just need basic 
shell sanitization (e.g. disable zsh's special wordsplitting).

> In summary, M4sh looks promising, but confusing. Now that it's no
> longer marked for internal use only, I hope the documentation that
> will enable users to use it will follow; however, I hope also that
> autoconf will continue to recommend and encourage the use of standards
> wherever possible, and not prefer proprietary solutions like M4sh.

I think you have a different definitions than I have for proprietary.

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.

Paolo