Square brackets cause errors in remote-exec

when using a line like this in remote-exec

"test=$(which python2.7); if [[ \"$test\" != '/usr/bin/python2.7' ]]; then echo 'failed to use /usr/bin/python2.7'; fi",

it will produce an error

11960 module.vpc.module.vpn.module.openvpn.null_resource.provision_vpn[0] (remote-exec): + [[ /usr/bin/python2.7 != /usr/bin/python2.7 ]]
11961 module.vpc.module.vpn.module.openvpn.null_resource.provision_vpn[0] (remote-exec): /tmp/terraform_751562885.sh: 13: /tmp/terraform_751562885.sh: [[: not found

I’m guessing I need to escape the square brackets somehow… what is the recommended method for this?

Hi @queglay,

As far as I can tell from the output you shared, the square brackets seem to have successfully arrived at the shell and it seems to be the shell itself that is rejecting this syntax.

I think the problem here might be that this isn’t executing in the shell you are expecting: this [[ ... ]] syntax is not POSIX-standard – it’s an extension in bash and maybe some other shells – and so if this script is running in a different shell such as dash then the syntax may not be supported.

If you want to use bash extensions then probably best to force it to run in Bash by including an explicit interpreter line in the script:

  inline = [
    <<EOT
      #!/bin/bash
      test="$(which python2.7)"
      if [[ "$test" != '/usr/bin/python2.7 ]]; then
        echo 'failed to use /usr/bin/python2.7'
      fi
    EOT
  ]

I used the <<EOT syntax here, rather than the single-line quoted string syntax, to put the interpreter specification on a line of its own while keeping the result relatively readable. However, I didn’t test the script so I’m sorry if I introduced any errors into the script itself in the process; adding that extra #!/bin/bash to the front is the main thing I’m suggesting here.

1 Like

Ahh of course! Thankyou so much for catching that, I’m sure that solves it.