Measure twice, code once: Hardcoding dangerous scripts
Nils Norman Haukås Aug 19
Now here's a trick for life when dealing with potentially destructive commands. Hardcode everything except the password.
Consider this script.
#!/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 184.108.40.206 \ 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.
First published on nilsnh.no.
when should you quit your current job to pursue your goals. I see postings all the time of how people quit their job saved up money for x time and begin working toward there goal of getting a better career. I want to talk about the other half of this for a minute of is this really a smart move?