Defect: install.sh check bash version

[jbmaggard]

Defect/Bug Report

• OpenCoarrays Version: 1.9.2
• Fortran Compiler: gfortran 7.2.0
• C compiler used for building lib: gcc 7.2.0
• Installation method: install.sh
• Output of uname -a: "Linux login4 2.6.32-696.6.3.el6.x86_64 tests dis_transpose: test passed  #1 SMP Wed Jul 12 14:17:22 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux" running linuxbrew master, updated
• MPI library being used: MPICH 3.2
• Machine architecture and number of physical cores: Dual Core, Intel Xeon E5-2670 v2, 10-core, 2.5GHz
• Version of CMake: 3.9.3

Observed Behavior

/bin/bash --version: GNU bash, version 4.1.2(2)-release (x86_64-redhat-linux-gnu)

~/.linuxbrew/bin/bash --version: GNU bash, version 4.4.12(1)-release (x86_64-unknown-linux-gnu)

When executing install.sh -d -e under /bin/bash (version 4.1.2(2)), script hangs at:

#### Functions added by Damian Rouson

# Get the top element from the stack and return the stack
# to its state before invocation of the function.
#
# Usage: stack_peek name var
#
# Example:
#    stack_peek mystack top
#    echo "Got $top"
function stack_peek
{
  : "${1?'Missing stack name'}"
  : "${2?'Missing variable name in stack_peek'}"

  if no_such_stack "$1"
  then
      echo "No such stack -- $1" >&2
      return 1
  fi

  stack_pop "$1" "$2"
  eval argument_name="\$$2"
  # shellcheck disable=SC2154
  stack_push "$1" "$argument_name"
}
stack_new dependency_pkg
+ stack_new dependency_pkg
+ : dependency_pkg
+ stack_exists dependency_pkg
+ : dependency_pkg
+ eval '_i=${_stack_dependency_pkg_i:-}'
_i=${_stack_dependency_pkg_i:-}
++ _i=
+ [[ -z '' ]]
+ return 1
++ uname
+ [[ Linux == \D\a\r\w\i\n ]]
+ eval 'declare -ag _stack_dependency_pkg'

Expected Behavior

When executing install.sh under bash 4.1.12(2), script executes and produces clean build/test/install.

Steps to Reproduce

Execute install.sh under bash 4.4.12(1).

[zbeekman]

Hmmm this is going to be very hard for us to debug. I'm guessing that this is a bash bug, but I'll try to look into it. That eval looks a bit suspicious.

[zbeekman]

Also, it would be nice to know which OS (which particular RedHat/Fedora) and version you're using, because I can't think of an easy way to install that particular version of bash. If it's a freely available (not RHEL) then I can fire up a VM.

[jbmaggard]

/bin/bash (4.1.2(2)) is CentOS 6.

[zbeekman]

Ah, great! CentOS is perfectly reasonable and something we should be able to support. I'll fire up a VM to investigate.

…

On Sat, Oct 7, 2017 at 10:29 PM jbmaggard ***@***.***> wrote: /bin/bash (4.1.2(2)) is CentOS 6. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#455 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAREPH4G-eZ-DGuhb9-Y7I4gIDnFUK1rks5sqDOegaJpZM4PxUv7> .

[zbeekman]

I have reproduced this. Executing install.sh without args causes it to return without error, nearly immediately, without doing anything useful.

[zbeekman]

FYI, this is due to a problem with the stack.sh implementation. It looks like it has been fixed upstream: https://github.com/bmc/lib-sh/blob/master/stack.sh but we need to incorporate @rouson's changes again to accommodate set -o errexit and set -o nounset.

[rouson]

@zbeekman Thanks for finding the upstream fix! I wasn't aware of that. I'll take a quick look at merging in the upstream changes this evening, but if it takes me more than a few minutes, I'll likely have to put it off until later in the week.

[zbeekman]

yeah I started to look at it, and it seems like we've diverged somewhat substantially. I applied the fix that said it made it work for bash < 4.3 (i.e. 4.1) but then encountered other issues (some yacc don't like/have --version) i.e. CentOS6 / RHEL6. These are pretty common HPC OSes so it will be nice to get them fixed. I may have time tonight.

…

On Mon, Oct 9, 2017 at 2:34 PM Damian Rouson ***@***.***> wrote: @zbeekman <https://github.com/zbeekman> Thanks for finding the upstream fix! I wasn't aware of that. I'll take a quick look at merging in the upstream changes this evening, but if it takes me more than a few minutes, I'll likely have to put it off until later in the week. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#455 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAREPCG_jnTG7GrNkO6iZfbYuNCmSqfEks5sqmdTgaJpZM4PxUv7> .

[zbeekman]

@jbmaggard #456 should take care of the stack.sh issue. I found two other problems that I fixed, but on CentOS 6 I still can't get through install.sh because curl doesn't like the ftp://ftp.gnu.org:/path/to/tarball.... url. The logic is a bit complicated to follow the strategy for choosing a downloader and url.

@rouson: which cases/OSes require FTP? It would be nice to make the URLs more canonical, not tailored to FTP.