As I will be deploying this script on multiple machines with the very same system Linux Mint 18 with rather same configuration, I would like to be semi-sure I won't screw things up much. This little script will run every day from crontab and will be logged into syslog.

Conditions were:

  1. Code Readability
  2. Output Readability
  3. Colored Headings
  4. Attempt to correct things
  5. Clean-up after update

My current idea is simple:




echo -e "step 1: ${GREEN}pre-configuring packages${NOCOLOR}"
sudo dpkg --configure -a


echo -e "step 2: ${GREEN}fix and attempt to correct a system with broken dependencies${NOCOLOR}"
sudo apt-get install -f


echo -e "step 3: ${GREEN}update apt cache${NOCOLOR}"
sudo apt-get update


echo -e "step 4: ${GREEN}upgrade packages${NOCOLOR}"
sudo apt-get upgrade


echo -e "step 5: ${GREEN}distribution upgrade${NOCOLOR}"
sudo apt-get dist-upgrade


echo -e "step 6: ${GREEN}remove unused packages${NOCOLOR}"
sudo apt-get --purge autoremove


echo -e "step 7: ${GREEN}clean up${NOCOLOR}"
sudo apt-get autoclean


Current visual output:

Upgrade Script


1 Answer 1


The output of your script is lovely, but it strikes me as a work in progress. There's nothing wrong with what is there, but it seems a few major pieces are missing.

error checking

What happens if one of the steps fails? As it stands the script will diligently proceed to the next step. If you actually checked the return codes from your apt commands you would also get a chance to use the RED color that seemed wasted in the comments above.


You mention logging, but there is no such thing in the script. Adding this would not be hard. If you want your messages to go to the screen and a log you could add functions that log and write to the screen. logger is handy way to add to the system logs, but you could write to your own $LOGFILE too with something like

echo "step $STEP: $MSG" >> $LOGFILE


Shouldn't there be docs somewhere? A link to a wiki page or something in the script would help folks figure out what is up. Providing help from within the script if a -h is provided is a good habit to get into.

rewrite based on above



mylog() {

        echo -e "step $STEP: ${GREEN}${MSG}${NOCOLOR}"
        logger "step $STEP: $MSG"

myfail() {

        echo -e "step $STEP ERROR: ${RED}${MSG}${NOCOLOR}"
        logger "step $STEP ERROR: $MSG"

# handle command line options
if [[ $1 == "-h" ]]; then
        echo "usage: $0"
        echo " -h prints help"

        exit 1

# step 1
mylog 1 "the start"
echo foo

# step 2
mylog 2 "a middle"
echo bar

# step 3
mylog 3 "the end"
echo baz
if [[ $? == 0 ]]; then
        myfail 3 "nothing really"


It is a good habit to run your scripts through shellcheck.net. Even my short rewritten example has one thing that could be improved.

  • \$\begingroup\$ Should variables in assignments and conditions not be quoted? i.e. STEP="$1" instead of STEP=$1. I know this is an old question, but I just came across it and am honestly wondering. \$\endgroup\$
    – iuvbio
    Commented Jul 22, 2019 at 18:24
  • \$\begingroup\$ It probably should be quoted. I'm surprised shellcheck didn't complain about that. \$\endgroup\$
    – chicks
    Commented Jul 22, 2019 at 19:10
  • \$\begingroup\$ Same here, it's only because it wasn't marked that I ask. It does not complain when the variable is used in an assignment or conditional, but it does complain when it is an argument to a command, so I thought that might be a rule. It's also not mentioned in their wiki for SC2086. Anyway, thanks for the clarification. \$\endgroup\$
    – iuvbio
    Commented Jul 22, 2019 at 20:22
  • \$\begingroup\$ @iuvbio No, when assigning to a variable like var1=$1 you do not have to quote, ever. \$\endgroup\$ Commented Sep 28, 2021 at 9:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.