Re: ltmain.sh quoting fix.

[Gary V . Vaughan]

Hi Andrew,

It has been a while since you sent me this, so I am quoting the whole thing 
for context.  After some deliberation, I find myself swayed by your argument.
In an ideal world, only variables which may contain embedded spaces (e.g. 
pathnames) should be always quoted, and other variables should be defaulted 
correctly but left unquoted to allow occasional errors to be located quickly. 
 In fairness, this is probably a lofty goal, so applying your patch is a net 
win, even though it has the disadvantages I cited when I initially rejected 
the patch.

I quite like the idea of using ${var?}, but I have seen it used so rarely 
that I wonder how portable it is given all the brain damaged bourne shells 
out there.

I'll commit your patch to HEAD presently.  Sorry for the delay.

Cheers,
        Gary.

In an ancient message, Andrew C. Feren wrote:
> Gary V. Vaughan <address@hidden> writes:
> > On Friday 25 May 2001 12:47 am, Andrew C. Feren wrote:
> > > I actually discovered this while compiling an other package (Ethereal)
> > > which bundles a copy of libtool 1.4.  I've included a minimal fix to
> > > correct the problem I was seeing and a more complete fix along with a
> > > patch for sh.test.
> > >
> > > The basic problem is that test "never sees" uninitialized variables
> > > that are not quoted.
> > >
> > > test $some_unset_var = test_case
> > >
> > > vs
> > >
> > > test "$some_unset_var" = test_case
> > >
> > > in the former case you get the following error message (assuming my sh
> > > :-) test: argument expected
> >
> > I almost applied this patch.
>
>       Have the current bugs been fixed or should I come up with a
>       patch for the specific lines that are causing problems.
>
> > However, I think that it is important to be able to tell if these
> > variables are left unset. If they are not set (usually to either `yes' or
> > `no') then depending on the style of the test a blank would effectively
> > be defaulting to one of the set values.  Clearly, this is wrong, and we
> > want to be able to catch it as early as possible, whereas quoting the
> > variables will mask the immediate bug by effecting a pseudo-random
> > default.
>
>       I understand your point, but I am not sure that I agree.
>       First it seems that the current approach didn't necessarily
>       accomplish the goal since a release went out that didn't run.
>
>       Second I think that if you want know if a variable is unset
>       then perhaps a better approach is in order.  In my experience
>       different versions of test produce different results.  All
>       somewhat cryptic.
>
> Solaris sh
> $ test $some_unset_var = test_case
> test: argument expected
>
> Solaris ksh
> $ test $some_unset_var = test_case
> ksh: test: argument expected
>
> Solaris bash
> $ test $some_unset_var = test_case
> test: =: unary operator expected
>
>         Even when, as in my case, you have a pretty good idea what is
>         causing the error finding the line with the problem is still
>         something of a pain since there is no indication as to which
>         variable was unset.  Using the ${var?} is perhaps a better way
>         to accomplish this.
>
> Solaris sh
> $ test ${some_unset_var?} = test_case
> some_unset_var: parameter null or not set
>
> Solaris ksh
> $ test ${some_unset_var?} = test_case
> ksh: some_unset_var: parameter null or not set
>
> Solaris bash
> $ test ${some_unset_var?} = test_case
> bash: some_unset_var: parameter null or not set
>
>         Finally, your argument is inconsistent with what I find in
>         ltmain.sh.  Granted the following is a somewhat crude test,
>         but by my count there are more quoted variables than unquoted
>         by a substantial margin
>
> $ grep 'test "\$' ltmain.sh | wc -l
>      149
> $ grep 'test \$' ltmain.sh | wc -l
>       68
>
>       I am interested in working out a solution to this problem both
>       in general and the specific issues that I am experiencing.  I
>       see 4 basic approaches to this problem
>
> 1) remove all quoting and let ltmain.sh continue to fail with the
> current error.  (Are there implications for anything with embedded
> spaces?)
>
> 2) Change all variables to ${var?}.  This will produce an, IMO
> reasonable, error message regardless of quoting.  This does add a few
> extra characters.  It should be possible to construct a test to unsure
> that people don't accidentally forget these extra characters.  Should
> be a simple variation of the test I submitted to test for quoting.
>
> 3) Quote all variables and allow the implicit default.  In some cases
> (mine for example) this will actually do the right thing.  Of course
> when this doesn't do the "right thing" you are correct that locating
> the error may be more difficult.
>
> 4) Make the defaults explicit.  ${var:-no} for example.  It isn't
> clear to me that this has any real advantage over 3, but I have
> included it here for completeness.
>
>         Any other thoughts or suggestions?
>
> > Cheers,
> >     Gary.
> > --
> >   ())_.  Gary V. Vaughan     gary@(oranda.demon.co.uk|gnu.org)
> >   ( '/   Research Scientist  http://www.oranda.demon.co.uk       
> > ,_())____ / )=   GNU Hacker          http://www.gnu.org/software/libtool 
> >  \'      `& `(_~)_   Tech' Author       
> > http://sources.redhat.com/autobook    =`---d__/

-- 
  ())_. Gary V. Vaughan     gary@(oranda.demon.co.uk|gnu.org)
  ( '/  Research Scientist  http://www.oranda.demon.co.uk       ,_())____
  / )=  GNU Hacker          http://www.gnu.org/software/libtool  \'      `&
`(_~)_  Tech' Author        http://sources.redhat.com/autobook   =`---d__/