Can't add another script in bash - bash

Question

I wrote a bash script which calls another script in the same folder. I am doing this by simply putting ./email_pacotes.sh in the main script
#awk '{print $2}' >> /tmp/lista_pacotes.log adiciona resultado ao arquivo /tmp/tmp_pacotes_adicionados.log
echo "\nPacotes adicionados até" $(date) "\n" >> /tmp/tmp_pacotes_adicionados.log
cat /tmp/diferencas.log >> /tmp/tmp_pacotes_adicionados.log
./email_pacotes.sh
#adiciona resultados anteriores
cat /tmp/pacotes_adicionados.log >> /tmp/tmp_pacotes_adicionados.log
I thought that it was working correctly, but I had to debug the script for other reasons and I found out it wasn't adding the second script the first time a run the main script.
I was getting the following message:
[...]
./email_pacotes.sh: 17: ./email_pacotes.sh: [[: not found
./email_pacotes.sh: 17: ./email_pacotes.sh: [[: not found
./email_pacotes.sh: 17: ./email_pacotes.sh: [[: not found
./email_pacotes.sh: 17: ./email_pacotes.sh: [[: not found
./email_pacotes.sh: 17: ./email_pacotes.sh: [[: not found
[...]
This happens when I run the script the first time I put it in a folder. If I run it again, the message doesn't show anymore, so I guessing it is not a problem with the syntax. I also thought could be something with permissions, but I changed both scripts to 0777 and the message persists.
Is this a normal behaviour? What could be causing this?
Obs1: I am debugging the main script using the -x option.
Obs2: I made another test now. It keeps throwing the same message, but at certain point it finally calls the script. So maybe is just the time to find the file or throw a exception?

Answer 1

From the error, I'm pretty sure you're running the second script with a shell other than bash. The [[ ]] conditional is supported by bash (and zsh and maybe some other shells), but is not standard and there are other shells that don't support it. So if you want to use that (or any other nonstandard bash features), you need to use a proper shebang line in that script. Generally, that means you need to start the script with #!/bin/bash (or maybe #!/usr/bin/env bash), not with #!/bin/sh.
There's another thing that worries me, though. Running the second script with ./email_pacotes.sh will look for it in the current working directory, which is inherited from the process that ran the first script, and could be pretty much anywhere. If you want it to look for the second script in the same directory the first script is in, the best way is to locate the first script with something like "$(dirname "$BASH_SOURCE")" (and guess what -- BASH_SOURCE is a bash-only feature, so start the first script with a bash shebang as well). Then you can either refer to the second script (and any other relevant files) by explicit path:
#!/bin/bash
...
scriptDir="$(dirname "$BASH_SOURCE")"
if [[ ! -d "$scriptDir" ]]; then
echo "Something's terribly wrong; I can't find myself!" >&2
exit 1
fi
...
"$scriptDir/email_pacotes.sh"
or have the script cd to its own directory and then use relative paths:
#!/bin/bash
...
cd "$(dirname "$BASH_SOURCE")" || {
echo "Something's terribly wrong; I can't cd to my own directory!" >&2
exit 1
}
...
./email_pacotes.sh
I prefer the first approach, because if the any of the scripts accepts paths (e.g. as arguments), the user will expect those paths to be interpreted relative to where the user was when they ran the script, not relative to where the script itself is; cding in the script will break this.