Measure twice, code once: Hardcoding dangerous scripts
Now here’s a trick for life when dealing with potentially destructive commands. Hardcode everything except the password.
Consider this script.
push-to-stage.sh
#!/usr/bin/env bash
# initialize environment variables
# source: http://stackoverflow.com/a/30969768
set -o allexport
source .env
set +o allexport
# hardcode target because we do not mistakenly want to push to prod
mysql --compress --verbose \
-u dbuser -p$STAGING_PASSWORD \
--host 123.123.123.123 \
staging-database < db-dump/dump.sql
The script above fetches the $STAGING_PASSWORD
from an adjacent .env
file, which is never added to the git repository. The script calls mysql
which imports a local database export into the staging database, and destructively overwrites its contents. This is how we can update the staging (test) database with a database export from the production (live) database.
A script like this should not be configurable.
Take it from me, accidentally deleting a database is painful. So, to spare the hair of me and my colleagues at Netlife, I choose to hardcode potentially dangerous scripts.
![Picture of a chain saw.](https://nilsnh.no/2018/08/19/measure-twice-code-once-hardcoding-dangerous-scripts/michael-fenton-506489-unsplash_hu3d03a01dcc18bc5be0e67db3d8d209a6_6200550_800x0_resize_q85_box.jpg)
Terminal commands are power tools that get the job done. Photo by Michael Fenton on Unsplash.