Question

I’m working on a script that has gotten so complex I want to include an easy option to update it to the most recent version. This is my approach:

set -o errexit

SELF=$(basename $0)
UPDATE_BASE=http://something

runSelfUpdate() {
  echo "Performing self-update..."
  # Download new version
  wget --quiet --output-document=$0.tmp $UPDATE_BASE/$SELF
  # Copy over modes from old version
  OCTAL_MODE=$(stat -c '%a' $0)
  chmod $OCTAL_MODE $0.tmp
  # Overwrite old file with new
  mv $0.tmp $0
  exit 0
}

The script seems to work as intended, but I’m wondering if there might be caveats with this kind of approach. I just have a hard time believing that a script can overwrite itself without any repercussions.

To be more clear, I’m wondering, if, maybe, bash would read and execute the script line-by-line and after the mv, the exit 0 could be something else from the new script. I think I remember Windows behaving like that with .bat files.

Update: My original snippet did not include set -o errexit. To my understanding, that should keep me safe from issues caused by wget.
Also, in this case, UPDATE_BASE points to a location under version control (to ease concerns).

Result: Based on the input from these answers, I constructed this revised approach:

runSelfUpdate() {
  echo "Performing self-update..."

  # Download new version
  echo -n "Downloading latest version..."
  if ! wget --quiet --output-document="$0.tmp" $UPDATE_BASE/$SELF ; then
    echo "Failed: Error while trying to wget new version!"
    echo "File requested: $UPDATE_BASE/$SELF"
    exit 1
  fi
  echo "Done."

  # Copy over modes from old version
  OCTAL_MODE=$(stat -c '%a' $SELF)
  if ! chmod $OCTAL_MODE "$0.tmp" ; then
    echo "Failed: Error while trying to set mode on $0.tmp."
    exit 1
  fi

  # Spawn update script
  cat > updateScript.sh << EOF
#!/bin/bash
# Overwrite old file with new
if mv "$0.tmp" "$0"; then
  echo "Done. Update complete."
  rm \$0
else
  echo "Failed!"
fi
EOF

  echo -n "Inserting update process..."
  exec /bin/bash updateScript.sh
}

Answer 1

(At least it doesn’t try to continue running after updating itself!)

The thing that makes me nervous about your approach is that you’re overwriting the current script (mv $0.tmp $0) as it’s running. There are a number of reasons why this will probably work, but I wouldn’t bet large amounts that it’s guaranteed to work in all circumstances. I don’t know of anything in POSIX or any other standard that specifies how the shell processes a file that it’s executing as a script.

Here’s what’s probably going to happen:

You execute the script. The kernel sees the #!/bin/sh line (you didn’t show it, but I presume it’s there) and invokes /bin/sh with the name of your script as an argument. The shell then uses fopen(), or perhaps open() to open your script, reads from it, and starts interpreting its contents as shell commands.

For a sufficiently small script, the shell probably just reads the whole thing into memory, either explicitly or as part of the buffering done by normal file I/O. For a larger script, it might read it in chunks as it’s executing. But either way, it probably only opens the file once, and keeps it open as long as it’s executing.

If you remove or rename a file, the actual file is not necessarily immediately erased from disk. If there’s another hard link to it, or if some process has it open, the file continues to exist, even though it may no longer be possible for another process to open it under the same name, or at all. The file is not physically deleted until the last link (directory entry) that refers to it has been removed, and no processes have it open. (Even then, its contents won’t immediately be erased, but that’s going beyond what’s relevant here.)

And furthermore, the mv command that clobbers the script file is immediately followed by exit 0.

BUT it’s at least conceivable that the shell could close the file and then re-open it by name. I can’t think of any good reason for it to do so, but I know of no absolute guarantee that it won’t.

And some systems tend to do stricter file locking that most Unix systems do. On Windows, for example, I suspect that the mv command would fail because a process (the shell) has the file open. Your script might fail on Cygwin. (I haven’t tried it.)

So what makes me nervous is not so much the small possibility that it could fail, but the long and tenuous line of reasoning that seems to demonstrate that it will probably succeed, and the very real possibility that there’s something else I haven’t thought of.

My suggestion: write a second script whose one and only job is to update the first. Put the runSelfUpdate() function, or equivalent code, into that script. In your original script, use exec to invoke the update script, so that the original script is no longer running when you update it. If you want to avoid the hassle of maintaining, distributing, and installing two separate scripts. you could have the original script create the update script with a unique in /tmp; that would also solve the problem of updating the update script. (I wouldn’t worry about cleaning up the autogenerated update script in /tmp; that would just reopen the same can of worms.)