don't edit bash scripts while they're running

When a Bash script runs it exhibits some interesting behaviour that doesn't seem to be an issue in other (real) scripting languages. Normally, running a script means the whole file is read into memory before it's executed, so any changes to the script while it's running don't affect the current execution.

Not so for Bash, which will continue reading commands from the same byte offset in the modified file, even if that's now the middle of a command.

Of course, under normal circumstances scripts aren't edited while running so this shouldn't be much of an issue. However, during development it's certainly a possibility when it comes to long-running scripts, or ones that contain commands that pause execution, like read.

It's easy to forget to kill a script before editing it, which might leave it in a state where it's waiting for user input of some form. It's just as easy to forget that Bash behaves like this, and upon your return to the terminal window to let the script happily continue from where it left off... wherever that now may be.

Most of the time when this happens you'll just get a command not found error (or syntax error) because when chopping a line in two it's not that likely that the second half is valid. But if one day the stars align (think of an unfortunate splitting of confirm), you may find yourself running a command that's not only valid, but also destructive. So be careful.