Safe self-update

[pcrockett]

So, Bash has a unique way of executing scripts compared to other languages. It executes commands line-by-line while it is reading lines. Which means if your script changes while it's being executed, Bash will just continue to read the same file, reading and executing commands from the new updated version. This leads to some interesting behavior, including making it really hard to predict what line of code will be executed next after the script is updated.

Compare that to other languages, which usually read and parse the whole file before beginning execution: File changes don't affect processes that are already running.

A workaround to make Bash behave like other languages is to use a pattern like this:

#!/usr/bin/env bashmain() {
# do stuffexit$?
}
main

This forces Bash to parse the entire main function and execute it as a whole, regardless if the script changes during execution. And the exit call at the end of main makes sure that Bash won't execute any new lines that might appear after the main call.

Which leads me to my actual use case: I want to use rush (which is built with Bashly) to update rush. Bashly almost uses the pattern above, which is great. However it doesn't put an exit command at the end of run, so updating rush via rush is still pretty unsafe.

I know this is a pretty narrow edge case, but it would make sense to support scripts than can safely self-update. Thoughts?

[DannyBen]

Some thoughts in no particular order:

exit - In regards to placing exit in bash (or any code) - I usually do it very sparingly, if at all. This is a "hard stop" which is not always desired since the script can be a guest in another system.

exec - I was facing similar problems in Ruby. The way I solved it was using exec to end the current process and start a new process at the same time.

#!/usr/bin/env bash# test.shecho"hello"exec bash -c "echo # running update >> test.sh"echo"world"

For example, here we create a temporary update script and exec it:

#!/usr/bin/env bash# test2.sh
cat << 'EOF' > ./update.sh#!/usr/bin/env bashecho "Updating"echo "# some updated lines" >> test2.shEOF# Run the update script
chmod +x ./update.sh
exec ./update.sh

[DannyBen]

Wait, why not?

I think we can easily create a rush package in your rush repo to update rush, so you run "rush rush" and it will employ the tactic mentioned above? No?

I avoid creating "self update" in most of my work, since
a) most CLI apps do not have it
b) the way people install it varies

[pcrockett]

In rush, when it's executing the package's main, it does so like this:

./main

so if my main script updates the rush script, then rush will continue running and potentially get into trouble. The problem would be resolved, however, if rush did

exec ./main

then it would be safe for my package to update rush.

[DannyBen]

You are right.
Rush needs to continue its normal execution after the package, cannot use exec here...

[DannyBen]

@pcrockett - it was brought to my attention that while trying to rewrite a bash script while it is running is unsafe, using mv temp-new-script old-script should be safe.

If this is indeed the case, then creating a rush repo main that performs an update like this should work.

EDIT: Scratch that. I was unable to mv to a running script.

This is the only option I found to be working so far:

# main#!/usr/bin/env bashecho"updating rush"
(
sleep 3 # or some other waiting logicecho"# updated">> rush.sh # perform the update
) &echo"update will run in the background"

[pcrockett]

ew. i think i'll just write a separate dedicated rush updater script, which i install via rush. just requires a bit of copy / paste from my rush-repo.