Nut upsdev - Nov 2006 - Re: [nut-commits] svn commit r578 - in trunk: . docs

Charles Lepple wrote:
> 
> On 11/9/06, Peter Selinger <selinger-guest@alioth.debian.org> wrote:
> > Author: selinger-guest
> > Date: Fri Nov 10 05:57:37 2006
> > New Revision: 578
> > @@ -566,72 +567,72 @@
> >
> >  AC_MSG_CHECKING(driver path)
> >  AC_ARG_WITH(drvpath,
> > -AC_HELP_STRING([--with-drvpath=PATH], [where to install ups drivers
(<prefix>/bin)]),
> > +AC_HELP_STRING([--with-drvpath=PATH], [where to install ups drivers
(EPREFIX/bin)]),
> >  [      case "${withval}" in
> >         yes|no)
> >                 AC_MSG_RESULT(using default)
> > -               eval conftemp="${DRVPATH}"
> > +               eval eval conftemp="${DRVPATH}"
> 
> Is the double eval intentional? I don't have time to test this before
> work today, but it seems like the first eval would result in an
> assignment, whereas the second one might not be correct.
Hi Charles,

yes, it's intentional, and in fact necessary. I had some fun figuring
this out last night, so I am glad you asked. Consider this:

bash$ prefix=/foo
bash$ exec_prefix='${prefix}'
bash$ DRVPATH='${exec_prefix}/bin'
bash$ echo ${DRVPATH}
${exec_prefix}/bin
bash$ eval echo ${DRVPATH}
${prefix}/bin
bash$ eval eval echo ${DRVPATH}
/foo/bin

Because of the double indirection, two "eval"'s are necessary.

You might wonder why I didn't use "" instead of '':

bash$ prefix=/foo
bash$ exec_prefix="${prefix}"
bash$ DRVPATH='${exec_prefix}/bin'
bash$ echo ${DRVPATH}
${exec_prefix}/bin
bash$ eval echo ${DRVPATH}
/foo/bin

or even

bash$ prefix=/foo
bash$ exec_prefix="${prefix}"
bash$ DRVPATH="${exec_prefix}/bin"
bash$ echo ${DRVPATH}
/foo/bin

The reason is that in this case, exec_prefix and DRVPATH would be
hardcoded in the generated Makefile, and could no longer be
overwritten by setting prefix and/or exec_prefix at "make" time.
(Overwriting it at "make" time is not a brilliant idea anyway, given
that the locations are already hardcoded in config.h; however, there
might be legitimate reasons for doing so, for instance during a staged
install).

There does remain, however, a small problem. If ${DRVPATH} and/or
${exec_prefix} contain spaces or shell specials, the above code
breaks. For example:

bash$ prefix='/foo bar'
bash$ exec_prefix='${prefix}/my stuff'
bash$ DRVPATH='${exec_prefix}/bin dir'
bash$ d="${DRVPATH}"
bash$ echo $d
${exec_prefix}/bin dir
bash$ eval d="${DRVPATH}"
bash: dir: command not found
bash$ eval d=\""${DRVPATH}"\"
bash$ echo $d
${prefix}/my stuff/bin dir
bash$ eval eval d=\""${DRVPATH}"\"
bash: stuff/bin: No such file or directory
bash$ eval eval d=\\\"\""${DRVPATH}"\"\\\"
bash$ echo $d
/foo bar/my stuff/bin dir

So it seems that I should have inserted multiple quotes.

Thanks, as usual, for being vigilant! -- Peter

On 11/10/06, Peter Selinger <selinger@mathstat.dal.ca>
wrote:
> The reason is that in this case, exec_prefix and DRVPATH would be
> hardcoded in the generated Makefile, and could no longer be
> overwritten by setting prefix and/or exec_prefix at "make" time.
> (Overwriting it at "make" time is not a brilliant idea anyway,
given
> that the locations are already hardcoded in config.h; however, there
> might be legitimate reasons for doing so, for instance during a staged
> install).
That last reason is a key feature of auto-generated Makefiles that is
used by most binary packaging systems. I will try to find some time to
test the trunk on Debian, but your reasoning sounds right to an
autoconf non-expert.

-- 
- Charles Lepple