Re: `configure' slightly broken in texinfo tree

[Manfred Hollstein <manfred at s-direktnet dot de>]

I don't know if this problem is still current (we had a bad mail lag
here). Anyway:

On Wed, 7 October 1998, 18:44:45, nix@esperi.demon.co.uk wrote:

 > Jeffrey A Law writes:
 > >   > The symptom is simple: upon typing `configure' (yes, even straight
 > >   > `configure' without any options at all), you get this:
 > > I just installed bash-2.02 and configured (on my i586-pc-linux-gnu laptop) and
 > > it configured just fine.
 > 
 > Whatever it is, it isn't bash - or not bash alone. I just built a
 > `bog-standard' bash without any options, with the standard CFLAGS &c,
 > with gcc-2.7.2.3, and configuring using that as my default shell gave
 > the same symptoms.
 > 
 > Hence I think we can rule bash bugs out, unless I somehow received a
 > corrupted bash source tarball long ago (not particularly likely).
 > 
 > > Something more subtle is going on.  I'd like to know what it is before we
 > > start hacking up texinfo (which we generally want to avoid doing, the closer
 > > it is to the standard distributions, the better).
 > 
 > What mystifies me is what the code in said configure.in is meant to
 > do. It reads
 > 
 > # We do this for the sake of a more helpful warning in doc/Makefile.
 > TEXMF='$(datadir)/texmf'
 > 
 > Am I being thoroughly thick, or will this execute the command named
 > `datadir', substitute its output into the command line, and stick a
 > `/texmf' on the end?

Nope, it's simply defining a shell variable ${TEXMF} whose value
is '$(datadir)/texmf'; '$(datadir)' shouldn't be interpreted as
"call the command datadir and insert its output here", because it's
quoted via ''; it's simply refering to the make macro $(datadir),
which you can find defined in nearly every GNU Makefile.

 > 
 > Given that
 > 
 > i) there is a variable named `datadir', and
again, it's not a shell variable, but a make macro.
 > ii) there is not guaranteed to be a command named `datadir', and,
 >     indeed, on my system there is not, and
that's OK, it shouldn't be.
 > iii) the *intent* of the code is probably to stick the expansion of the
 >      variable named `datadir' on the front of `/texmf', to get the
 >      probable location of the TeX data directory
no, see above.
 > 
 > how does it ever work on anyone's system? Do most people have a
 > command `datadir' that outputs the value of ${datadir} on stdout? Do

Using the curly brackets {} instead of () does only paper over the
fact, that your shell is somehow "evaluating" '$(datadir)' instead of
"literally copying" the string. It works for you, because "make"
treats $(datadir) and ${datadir} identically.

 > most people have some curious shell feature that turns unknown command
 > `foo' into a shell function that returns the variable named `foo'?

Definitely not ;-) BTW, I'm using Bourne Shell, GNU bash 1.14.7 and
2.02.1 without such behaviour.

 > 
 > -- 
 > `Suppose I manufacture band-aids. I sell them under the following
 >  license: "Buyer agrees to apply product only to his or her own body."'
 >   - Axel Boldt on commercial software licenses

manfred