Build 3.7 stable on Debian 7.0 wheezy - change bootrap to use bash

[e12e]

Hi,

I encountered a strange bug when trying to build povray 3.7 stable on Debian 7.0 wheezy:

git clone https://github.com/POV-Ray/povray.git povray.git
cd povray.git
git checkout 3.7-stable
cd unix
./prebuild.sh
#(...)
Run ../bootstrap
./bootstrap: 7: ./bootstrap: Bad substitution
sed: can't read ./Makefile.in: No such file or directory
# change bootstrap to use /bin/bash rather than /bin/sh (dash on my system):

$ git diff prebuild.sh
diff --git a/unix/prebuild.sh b/unix/prebuild.sh
index dc50640..e4cce04 100755
--- a/unix/prebuild.sh
+++ b/unix/prebuild.sh
@@ -709,7 +709,7 @@ case "$1" in
   *)
   echo "Create $bootstrap"
   cat << pbEOF > $bootstrap
-#!/bin/sh -x
+#!/bin/bash -x

 # bootstrap for the source distribution of POV-Ray $pov_version_base for UNIX
 # Written by $pov_config_bugreport

./prebuild.sh
#(Now runs without errors, and I can ./configure COMPILED_BY="your name <email@address>"
# and make as usual (confirmed with running unix/povray --benchmark

The closest similar thing I could find is this old Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=447022

I don't think this is the exact same thing, but I'd guess it is either a bug in Debian's autotools, or some strange interaction with the version Debian uses, and whatever povray upstram uses.

Not sure if I advocate making this change in povray, but thought I'd file a bug here so the (mis)behaviour (and possible fix) is documented.

[c-lipka]

From what I see, this seems to be a problem before the autotools even get involved. Something about the /bin/sh not comprehending some variable substitution in the code written to the "./bootstrap" script generated. Which is odd, because this portion of the prebuild stuff hasn't been touched for ages (not in the stable branch at any rate).

Can you attach the "./prebuild" file generated?

[e12e]

The only difference in the non-working, default /bootstrap and the fixed one is the shebang:

1c1
< #!/bin/sh -x
---
> #!/bin/bash -x

Attaching the non-working version below

.

[e12e]

Never mind -- I can no longer reproduce the error. Could be I ran this in some long-running shell/session and had some strange environment stuff set (I've since done an aptitude upgrade, and a reboot, so I can't recreate the situation). Very strange indeed. Closing -- must've been something odd on my end...