rm or wget fail in script based on a variable with a glob

Question

I'm having a trouble either with a filename glob in rm or with a variable expansion in wget.

In Ubuntu 16.04, I did the following:

set -a
export drt="/var/www/html"
export pma="[pP][hH][pP][mM][yY][aA][dD][mM][iI][nN]"
set +a
echo $drt # Got the above.
echo $pma # Got the above.

I then ran that an executable script (~/myScripts/tp_pma.sh):

#!/bin/bash
rm -rf ${drt}/${pma}*
wget -P ${drt} https://www.phpmyadmin.net/downloads/phpMyAdmin-latest-all-languages.zip
unzip ${drt}/${pma}*.zip
mv ${drt}/${pma}*/ ${drt}/phpmyadmin/
rm ${drt}/${pma}*.zip

The script succeeded partially:

1. The first rm might have succeed or might have caused all problems below.
2. The wget succeeded partially - a zip with a fresh copy of PMA was downloaded to my home directory instead to drt.
3. The unzip succeeded, the zip was unzipped and I got a latest phpmyadmin dir.
4. The mv failed (see error below). Because the directory phpMyAdmin-4.7.7-all-languages stayed in my home directory: it wasn't moved to drt and didn't have its name changed to phpmyadmin as I expected.
5. The last rm succeeded - the zip was deleted in my home directory.

I didn't get an error fr wget.

Also, it seems that the value of pma changed somehow to phpMyAdmin-4.7.7-all-languages. I didn't change it to that value.

What is likely to have failed here and why?

Answer 1

The unzip command you used extracts the archive in the directory unzip runs in, not where the archive lies in. You could either change to the directory containing the archive first, or use the -d option:

[-d exdir]
An optional directory to which to extract files. By default, all files and subdirectories are recreated in the current directory;

I would probably go with the chdir option:

#!/bin/bash
cd "$drt"
rm -r ${pma}*
wget https://www.phpmyadmin.net/downloads/phpMyAdmin-latest-all-languages.zip
unzip phpMyAdmin-latest-all-languages.zip
mv ${pma}*/ phpmyadmin/
rm phpMyAdmin-latest-all-languages.zip

Also, when you say "the value of pma changed somehow to phpMyAdmin-4.7.7-all-languages", do note that using the variable unquoted will cause it to be used as a filename pattern, so echo $pma* will show the names of the existing files if any match the pattern.

(I'm not exactly sure if the case-insensitive pattern is required; is there a realistic reason to expect the name format to change from phpMyAdmin to phpmyadmin?)

Answer 2

Suggestion for alternative script:

#!/bin/sh -ex

destdir="/var/www/html/phpmyadmin"

tmpdir=$(mktemp -d)
trap 'rm -rf "$tmpdir"' EXIT    # remove temporary directory on termination

wget -O "$tmpdir/archive.zip" \
    "https://www.phpmyadmin.net/downloads/phpMyAdmin-latest-all-languages.zip"

cd "$tmpdir" && {
    unzip archive.zip
    rm -f archive.zip

    # The only thing in the current (temporary) directory now is the
    # directory with the unpacked zip file.

    mkdir -p "$destdir"
    mv ./* "$destdir"/
}

If the archive unpacks into a subdirectory called phpMyAdmin-4.7.7-all-languages, the script will move this to /var/www/html/phpmyadmin so that the contents of the archive is available in /var/www/html/phpmyadmin/phpMyAdmin-4.7.7-all-languages.

The -ex makes the script

1. Exit as soon as a utility fails (-e), and
2. Output tracing info that could possibly be useful (-x).

Running this script twice will cause the last mv to fail as there is already a directory with the same name at the destination. The existing directory under $destdir will not be modified by this script.

When the script finishes, terminates because of an error, or is killed, the script will remove the temporary directory used for storing and unpacking the downloaded archive.

---

About root and security in this script:

If root permissions are required to write to $tmpdir then do not run the script as root! Instead insert sudo in front of the last mv.

There is, what I can see, no risk that any accidental removals will be carried out as the only parameter is $destdir and it's never used in any rm $var1/$var2* -type commands. In fact, unsetting $destdir will make the script fail gracefully at the mkdir.