Re: MKS Bourne Shell "case" weirdness...

[Lars J. Aas]

Regarding MKS sh and case/esac, I ran into another weird problem
during the MKS port which caused us to have to reorder a couple of
case switches in ltmain.in.  At line 1229, you will find

  -L*)
        dir=`$echo "X$arg" | $Xsed -e 's/^-L//'`
        # We need an absolute path.
        [...]
  -l*)

        if test "X$arg" = "X-lc" || test "X$arg" = "X-lm"; then
          case $host in

When this case switch gets to the argument -lXm, it enters the first
-L*) case instead of the -l*) case.  Reordering the two cased libtool
to enter the -l*) case (don't know if -L arguments failed though).
Anyways, we've now found out what that problem was caused by:

| http://www.mkssoftware.com/support/kb/articles/kb20014.asp
| 
| **************
| Knowledge Base Article #20014
| 
| 
| How do I make a case statement case-sensitive?
| 
| Product(s): Toolkit
| Operating System(s): Windows NT, 9x, 2000, ME
| Keyword(s): case, sensitive, DUALCASE
| 
| Question:
| How do I make a case statement case-sensitive?
| 
| Answer:
| Case statements use the file name generation feature of the shell which is
| normally case-insensitive. It is documented in the sh(1) reference. If you
| want to make file name generation case-sensitive then set the variable
| DUALCASE to a non-zero value.
| Example:
| 
|    DUALCASE=1
|    case "$1" in
|       -r*) echo r;;
|       -R)  echo R;;
|       *)   echo other
|    esac
|    unset DUALCASE
| 
| 
| Note that as of version 7.5 a new vaiable has been added. Setting
| TK_DUALCASE_IN_CASE_STATEMENTS to any value will make pattern-matching in
| case statements case-sensitive. When TK_DUALCASE_IN_CASE_STATEMENTS is not
| set, the DUALCASE environment variable determines whether or not
| pattern-matching is case-sensitive in the same way it does for file name
| generation.
| 
| ***********************

Setting up DUALCASE near the top of libtool solved the problem.
I've grepped through all the Libtool and Autoconf files for any mention
of the variable DUALCASE, but I found none.  I would probably go for
setting both DUALCASE and TK_DUALCASE_IN_CASE_STATEMENTS to try to get
sh to be as sane as possible, but I'm not completely sure I understand
the implications of the differences between the two yet (caffeine-level
is too low yet).

  Lars J