Am 22.02.15 um 10:38 schrieb Michael Olbrich:
>> What is the intention of this brace usage here?
> 
> It's valid bash syntax. A bit of history here:
> The standard for sh shells says, that the file descriptors up to 9 can be
> used inside the shell scripts. So that's what we used originally: With
> "5>&1" we create a file descriptor that we can later use to write to stdout
> when the normal stdout is redirected to the log file.
> However this solution as a problem: oder scripts can use the same file
> descriptor numbers and the output is send to the wrong place. This happened
> e.g. with configure scripts. So we changed it to:
> "exec {PTXDIST_FD_STDOUT}>&1". This is valid in bash and means that a new
> file descriptor is opened (with a currently unused number >= 10) and
> anything written to it is send to stdout. The file descriptor number is
> stored in the specified variable (PTXDIST_FD_STDOUT).

Thank you very much for the explanation. I've never heard or read about
this feature before.


> I don't know why the bash in Max OS X cannot handle this. Maybe it's too
> old? What version are you using?

Your assumption is right. My OS X is 10.9.5 (Mavericks) and way newer
than the Ubuntu 10.04.4 which is the oldest system where I use ptxdist
for my day-to-day work. That's why I didn't took the version numbers
into account. But I was wrong:

Ubuntu 10.04.4: bash 4.1.5(1)-release
OS X 10.9.5: bash 3.2.53(1)-release

Just for completeness: The redirection feature with the optional left
hand {var} notation was introduced in bash 4.1-alpha (see
http://git.savannah.gnu.org/cgit/bash.git/tree/CHANGES#n1550).

bash 4.1 was released on 31 Dec. 2009. :-)

> Maybe something like this works:
> exec 7>&1
> exec 8>&1
> export PTXDIST_FD_STDOUT=7
> export PTXDIST_FD_STDERR=8

I've installed a recent bash 4.3.33 via homebrew instead. But this is
only part of the fix, because the ptxdist' scripts have a hardcoded
shebang to /bin/bash.

Additionally I needed to replace the Apple bash:
# mv /bin/bash /bin/bash.apple
# ln -s /usr/local/bin/bash /bin/bash


Here is also a potential fix for the configure script to check for a
proper bash version. I've never worked with autoconf, so please check
the patch carefully.

diff -urd a/configure.ac b/configure.ac
--- a/configure.ac	2013-12-18 10:48:42.000000000 +0100
+++ b/configure.ac	2015-02-22 19:16:21.000000000 +0100
@@ -101,9 +101,9 @@
 # though the result /could/ be available to us directly as $BASH_VERSION we
 # don't want to use, or trust it, incase the user is specifying a different
 # bash executable.
-if `$BASH -c '[[ "$BASH_VERSION" \< "2.04" ]]'` ; then
+if `$BASH -c '[[ "$BASH_VERSION" \< "4.1" ]]'` ; then
     AC_MSG_ERROR([
-$PACKAGE_NAME requires at least version 2.04 of bash, you can download
a current
+$PACKAGE_NAME requires at least version 4.1 of bash, you can download a
current
 version of bash from ftp.gnu.org
 ])
 fi

This problem seems to be solved now.

I'm now facing the problem, that host-zlib is not getting compiled with
the compiler setup in ptxdist setup. But this is part of another story
coming soon.

Best regards,
Christoph


-- 
Christoph Rüdiger
Am Horber Wald 19
73765 Neuhausen

phone: +49 - 7158 - 12 84 670