Re: confused by m4 esyscmd expansion ... how to 'escape' nested quotes?

[OpenMacNews]

hi stepan,

> A few examples:

<snip>

the step-through + examples are *very* helpful, thx!

> Does it make sense now?


i thought it did; but, here's the current status/result --

starting with:

        changequote([,])
        define([MY_DNS_NAME],         [ns.mydomain.com])
        define([MY_HOST_NAME],        [machine.mydomain.com])

(a) this WORKS as expected

        define([MY_IP_ADDR],
	[esyscmd(dig @indir([MY_DNS_NAME]) indir([MY_HOST_NAME]) | grep 
indir([MY_HOST_NAME]) | grep -v DiG | grep -v ";"indir([MY_HOST_NAME]) | awk 
'{printf("%s", $ 5) }')])

expanding "10.0.0.6", without a CR, into all instances of MY_IP_ADDR in my 
template (e.g., "httpd.conf.m4")

(b) this, does NOT work:

        define([MY_IP_ADDR],
	esyscmd([dig @]MY_NS_NAME MY_HOST_NAME[ | awk 'index($ 0, "]MY_HOST_NAME[") == 
1 {printf("%s", $ 5) }']))

resulting in:

        -->  dig: couldn't get address for 'MY_NS_NAME': not found

(c) this, does NOT work:

        define([MY_IP_ADDR],
	esyscmd([dig @indir([MY_DNS_NAME]) indir([MY_HOST_NAME]) | awk 'index($ 0, 
"indir([MY_HOST_NAME])") == 1 {printf("%s", $ 5) }']))

resulting in:

        -->  sh: -c: line 1: syntax error near unexpected token `('
	     sh: -c: line 1: `dig @indir([MY_DNS_NAME]) indir([MY_HOST_NAME]) | awk 
'index($ 0, "indir([MY_HOST_NAME])") == 1 {printf("%s", $ 5) }''


(d) this, does NOT work:

(NOTE my 'quoting' here is similar to case(a), which does work ...)

        define([MY_IP_ADDR],
	[esyscmd(dig @indir([MY_DNS_NAME]) indir([MY_HOST_NAME]) | awk 'index($ 0, 
"indir([MY_HOST_NAME])") == 1 {printf("%s", $ 5) }')])

resulting in:

        -->  Usage: awk [POSIX or GNU style options] -f progfile [--] file ...
             Usage: awk [POSIX or GNU style options] [--] 'program' file ...
             POSIX options:          GNU long options:
             -f progfile             --file=progfile
             -F fs                   --field-separator=fs
             ...



soooo,

(a) works.  which is good!
(b) & (c) *may* be instances of awk not 'liking' the DNS "dig" output, rather 
than an m4 issue -- tho i'm not immediately certain of that ...
(d) raises the question of the DIFFERENCE in quoting between:

        define([...],esyscmd([dig ...           (which you'd recommmended ...)

and,

        define([...],[esyscmd(dig ...           (which seems to work 4 me ...)

so i need to read further & play with some local trial-n-error.

<just_my_$0.02>

> It's difficult for the authors of the documentation to
> understand how the text will be seen by newcomers' eyes...)

i admit being that 'newcomer', and _very much_ appreciate the recognition that 
--even WITH googling and RTFM'ing -- that sometimes it's a bit confusing to get 
started.

far too often, imho, folks on lists simply get 'nasty' if you ask a question 
that THEY know the answer to and feel you should too ... which i find so 
incredibly ironic.

> If yes, perhaps you could contribute to the
> GNU m4 documentation, so that future readers don't go through the same
> confusion.

that said, i'd be happy to contribute what i can -- when *I* figure it out 
myself! :-), and expand my macro to supporting multiple domain/IP discovery -- 
with a commented, practical example.

personally, i think using/mod'ing apache's conf is a commonplace enuf tast that 
folks might follow the example much more readily/capably than the somewhat 
simplistic/obscure (too me, that is) "examples" in the man page.

the general issue with such examples is that they too often limit their scope 
to simply the package at hand ... e.g., "only" within "m4" scope.

but, practical application -- as in my case -- typically includes the 
integration of, say, m4+awk+apache.

if find that your kind help is atypical (<-- good thing!) in that you're 
willing to both (a) work with a newcomer and (b) work 'outside' of 'your app'.

this, also, is a general challenge in integration across ANY two open-source 
apps  -- lots of finger pointing, and associated "try another list" comments.

i will be the first to agree that RTFM'ing is absolutely the right appraoch to 
any one package ... but, honestly, when you're trying to make 10, 20 or more 
'things' work together, it seldom readily solves the problem.

rather, help from patient, more experienced folks, does.  =)

</just_my_$0.02>

cheers,

richard