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.
