Re: m4 error at startup

On Thu, Oct 17, 2019 at 03:27:02PM -0400 I heard the voice of
Stefan Monnier, and lo! it spake thus:
> 
> No such luck: I took the /usr/bin/m4 above specifically from
> build/ctwm_config.h.

I'm sorry, can you reprase that in such a way that it makes me look
super smart instead of totally wrong?    :>


> Haven't been able to spot that either,

Mmm.  Well, we don't do anything particularly odd to the env or
anything when calling m4.  Now, here's one random guess:

> That's my question.  When I try to run `m4` manually with
>.
>     /usr/bin/m4 -s ~/tmp/foo.m4 -
>.....
> and a dummy foo.m4 file which has pretty much the same content as the
> file generated by ctwm, [...]

If you mean "foo.m4 has syscmd(...)", that would be something of a
difference.  We _do_ run m4 as a filter; the defs_file we include in
the command line isn't anything related to the user ctwmrc, it's just
our file of predefined vars (e.g., where the CLIENTHOST and
TWM_VERSION and the like are set).  You can keep it around for viewing
by running with `-k`.  The user ctwmrc gets plumbed up to m4's stdin.

So, maybe m4 is acting oddly for you when getting the syscmd() on
stdin?  I'm not sure how or why _that_ could be, but it's something,
anyway.  So give `m4 < ~/tmp/foo.m4` a whirl.


The test suite _does_ have a m4 test that runs the whole process, so
that'd be a way you could trigger it at will without having to run a
scratch ctwm.  I'm pretty sure the test won't _fail_, and not failing
means the output would be hidden, but at least it's run it.

After doing the regular `make test` once (to be sure everything's
built etc), I think you could `cd build ; ctest --verbose -R test_m4`
to run just that one test and see the output, too.


-- 
Matthew Fuller     (MF4839)   |  [email protected]
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
           On the Internet, nobody can hear you scream.