8
\$\begingroup\$

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:

#!/bin/bash

RED="\033[1;31m"
GREEN="\033[1;32m"
NOCOLOR="\033[0m"

echo

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

echo

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

echo

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

echo

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

echo

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

echo

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

echo

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

echo

Current visual output:

Upgrade Script

\$\endgroup\$
4
\$\begingroup\$

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.

logging

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

docs

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

#!/bin/bash

RED="\033[1;31m"
GREEN="\033[1;32m"
NOCOLOR="\033[0m"

mylog() {
        STEP=$1
        MSG=$2

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

myfail() {
        STEP=$1
        MSG=$2

        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
fi

# 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"
fi

finally

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

\$\endgroup\$
  • \$\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 Jul 22 at 18:24
  • \$\begingroup\$ It probably should be quoted. I'm surprised shellcheck didn't complain about that. \$\endgroup\$ – chicks Jul 22 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 Jul 22 at 20:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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