Portably setting environment variables from a shell script - bash

Question

I have this shell script that I would like to modify to ensure it runs correctly in a Bash environment.
Here's the script:
#!/bin/zsh
# Some constants. The first two will become env variables.
UPDATE_DNS_API_HOST="https://example.com"
UPDATE_DNS_API_URL="$UPDATE_DNS_API_HOST/my_end_point"
CURRENT_PUBLIC_IP=$(curl -s "$UPDATE_DNS_API_URL" | grep -o '".*"' | tr -d '"')
if [[ $PUBLIC_IP == $CURRENT_PUBLIC_IP ]]; then
echo "Current IP: "$CURRENT_PUBLIC_IP" already set."
else
response=$(curl -s -H "Content-Type: application/json" \
--data "$CURRENT_PUBLIC_IP" "$UPDATE_DNS_API_URL")
echo $response
export PUBLIC_IP="$CURRENT_PUBLIC_IP"
fi
Here are my questions:
Should I change the first line to #!/bin/bash
It's unclear when variables need quotes and when they don't, especially in conditional statements. Can you point me to some resources here?
I've seen variations in conditionals regarding single bracket vs double bracket. Which one should I be using?
After running the script, $PUBLIC_IP does not appear to be set. Is there a different way I should be setting the env variable?
Any other feedback is welcome.

Answer 1

One pertinent thing to keep in mind here is that UNIX processes can modify the environment variable for themselves and future children they start -- not their parents, without that parent process directly participating.
If your intent is to set a variable in the enclosing shell, one fairly common way to do this is to emit shell commands on stdout. This means that anything that isn't a shell command should be moved to stderr (which is appropriate practice anyhow, since stderr is specified as appropriate for informational text and status content).
This version does require bash, as opposed to /bin/sh, but uses printf '%q' to ensure that it's able to generate variable names in an eval-safe manner that all ksh derivatives (ksh, bash, zsh) should be able to read.
#!/bin/bash
# note that while this runs with bash, ksh and zsh will also be able to eval its output
# ...POSIX sh too, when there aren't nonprintable characters causing $''-style quoting
# ...to be used.
# usage: emit_cmd varname ...
#
# emit code that defines a variable when evaluated on stdout
emit_cmd() {
for varname; do
printf 'export %q=%q; ' "$varname" "${!varname}"
done
}
# Some constants. The first two will become env variables.
UPDATE_DNS_API_HOST="https://example.com"
UPDATE_DNS_API_URL="$UPDATE_DNS_API_HOST/my_end_point"
# print definitions of those variables to stdout
emit_cmd UPDATE_DNS_API_HOST UPDATE_DNS_API_URL
CURRENT_PUBLIC_IP=$(curl -s "$UPDATE_DNS_API_URL" | grep -o '".*"' | tr -d '"')
if [[ $PUBLIC_IP = $CURRENT_PUBLIC_IP ]]; then
echo "Current IP: $CURRENT_PUBLIC_IP already set." >&2
else
response=$(curl -s -H "Content-Type: application/json" \
--data "$CURRENT_PUBLIC_IP" "$UPDATE_DNS_API_URL")
echo "$response" >&2
PUBLIC_IP="$CURRENT_PUBLIC_IP" emit_cmd PUBLIC_IP
fi
If this script is saved under the name ip-lookup, the variables it defines can be imported into the current shell with:
eval "$(ip-lookup)"
Using this convention keeps compatibility with existing UNIX tools such as ssh-agent which need to modify environment variables.
Note that I'm keeping the existing conventions with respect to variable names, but if you have the opportunity, you should switch to lower-case names to comply with relevant POSIX convention.

Answer 2

If you want someone who invokes script.sh to run it under bash instead of zsh, then you must fix the shebang.
The inner pair of double quotes in:
echo "Current IP: "$CURRENT_PUBLIC_IP" already set."
are unorthodox and not a good idea. Use:
echo "Current IP: $CURRENT_PUBLIC_IP already set."
You probably want double quotes around:
echo "$response"
Otherwise, I think you're OK. As to resources, you can look at the Bash manual, or use facilities like shellcheck.com, or consult the Bash FAQ.
If you use [[ … ]] you'll probably be OK as written. The normal rules of shell syntax are suspended in [[ … ]] and confuse the hell out of people who learned Bourne shell and can't be bothered to learn that part of Bash.
You'd have to dot (. script.sh) or source (source script.sh) the script for the export PUBLIC_IP="$CURRENT_PUBLIC_IP" to have any effect on the calling shell. Otherwise, it sets the environment of the shell that runs the script, but doesn't affect the calling shell.
If you do decide you want to use the script with the dot command, then you should consider how many of the variables it sets should be unset before it finishes. And maybe whether any of them are set before it starts. Creating a function with all variables declared as local except the one you want to export makes life easier. You don't have to worry about this when the script is run as a separate process.