[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MKS Bourne Shell "case" weirdness...
From: |
Paul Eggert |
Subject: |
Re: MKS Bourne Shell "case" weirdness... |
Date: |
11 Jul 2003 11:51:24 -0700 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 |
"Lars J. Aas" <address@hidden> writes:
> Is it possible that this is a local problem for the given MKS user I
> am working with and that he may have a somewhat faulty MKS
> installation or something?
Possibly. It'd be nice if we could have another MKS user report what
happens. Or perhaps you or your user can consult the MKS bug database
(I can't; it's private).
> When porting our autoconf/automake/libtool setup for Coin
> (www.coin3d.org) to work on MKS, I found that I had to apply the
> following patch to Autoconf 2.57 to get the generated config.status
> script to behave:
Hmm, that looks pretty ad-hoc. Why did you need to change just these
case statements, and not all the case statements in Autoconf and
Libtool? What were the symptoms of the failure? Do you have a
small shell script that illustrates the problem?
Unless we understand the bug I'm a little leery of trying to insert
"true"s seemingly at random. For example, if it's an internal
buffer-boundary bug, a small change earlier in the script will cause
the bug to reappear, the "true"s notwithstanding.
That being said, does it fix things if you make one of the following
changes instead?
>From this:
for ac_file in : $CONFIG_HEADERS; do test "x$ac_file" = x: && continue
...
done
to this:
case $CONFIG_HEADERS in
?*)
for ac_file in $CONFIG_HEADERS; do
...
done;;
esac
or to this:
for ac_file in : $CONFIG_HEADERS; do
case $ac_file in
:)
...;;
esac
done
or to this:
for ac_file in : $CONFIG_HEADERS; do
test "x$ac_file" = x: && continue
...
done
or to this:
for ac_file in : $CONFIG_HEADERS; do
if "x$ac_file" != x:; then
...
fi
done
(Whew! You get the idea.)
Also, you might try changing the "; do" to a newline-do, e.g.:
for ac_file in : $CONFIG_HEADERS
do
case $ac_file in
:)
...;;
esac
done
in any of the above solutions, as we know of shells that screw up "; do"
in some cases.