Can a shell script indicate that its lines be loaded into memory initially?

Question

This is a little thing that bothers me every now and then:

1. I write a shell script (bash) for a quick and dirty job
2. I run the script, and it runs for quite a while
3. While it's running, I edit a few lines in the script, configuring it for a different job
4. But the first process is still reading the same script file and gets all screwed up.

Apparently, the script is interpreted by loading each line from the file as it is needed. Is there some way that I can have the script indicate to the shell that the entire script file should be read into memory all at once? For example, Perl scripts seem to do this: editing the code file does not affect a process that's currently interpreting it (because it's initially parsed/compiled?).

I understand that there are many ways I could get around this problem. For example, I could try something like:

cat script.sh | sh

or

sh -c "`cat script.sh`"

... although those might not work correctly if the script file is large and there are limits on the size of stream buffers and command-line arguments. I could also write an auxiliary wrapper that copies a script file to a locked temporary file and then executes it, but that doesn't seem very portable.

So I was hoping for the simplest solution that would involve modifications only to the script, not the way in which it is invoked. Can I just add a line or two at the start of the script? I don't know if such a solution exists, but I'm guessing it might make use of the $0 variable...

Answer 1

How about a solution to how you edit it.

If the script is running, before editing it, do this:

mv script script-old
cp script-old script
rm script-old

Since the shell keep's the file open as long as you don't change the contents of the open inode everything will work okay.

The above works because mv will preserve the old inode while cp will create a new one. Since a file's contents will not actually be removed if it is opened, you can remove it right away and it will be cleaned up once the shell closes the file.

Answer 2

Use an editor that doesn't modify the existing file, and instead creates a new file then replaces the old file. For example, using :set writebackup backupcopy=no in Vim.

Answer 3

Consider creating a new bang path for your quick-and-dirty jobs. If you start your scripts with: #!/usr/local/fastbash

or something, then you can write a fastbash wrapper that uses one of the methods you mentioned. For portability, one can just create a symlink from fastbash to bash, or have a comment in the script saying one can replace fastbash with bash.

Answer 4

Thanks for the answers, which propose great solutions for a single user who can control the environment. However, these would be problematic in a scenario with multiple users editing the same script file (while a long-running process is interpreting it); I don't want to assume that other people will edit the file in a special manner. Also, a wrapper in the shebang isn't going to be very portable; I want to be able to copy the script to a new system without installing anything else.

Anyway, here's the best solution I've been able to come up with... I could begin every shell script with this header:

#!/bin/sh
tail -n +3 $0 | sh -s $@; exit

Unfortunately, I think this will be limited by the size of the buffers used for standard streams; if the script file is too large, the end of it might not be streamed before someone has a chance to edit the file. So here's a clunkier solution:

#!/bin/sh                                                                       
TMPSCRIPT=$(mktemp); tail -n +3 $0 > $TMPSCRIPT; sh $TMPSCRIPT $@; exit
rm $0

Note that the temporary file is deleted immediately after the script begins executing, preventing a rogue user from sneaking in and editing it. (Of course, if a rogue user can get write permission to that file, you've got bigger problems to worry about.) As mentioned above, the old inode will still be accessible to the shell process even after the file is seemingly gone.

It's ugly, but it would be easy to create an emacs macro that writes this header on every shell script.

Does this seem reasonable?

Answer 5

If you use Emacs, try M-x customize-variable break-hardlink-on-save. Setting this variable will tell Emacs to write to a temp file and then rename the temp file over the original instead of editing the original file directly. This should allow the running instance to keep its unmodified version while you save the new version.

Presumably, other semi-intelligent editors would have similar options.

Answer 6

According to the bash documentation if instead of

#!/bin/bash
body of script

you try

#!/bin/bash
script=$(cat <<'SETVAR'
body of script
SETVAR)
eval "$script"

then I think you will be in business.

Answer 7

The best answer I've found is a very slightly variation on the solutions offered to http://stackoverflow.com/questions/2285403. Thanks to camh for noting the repost!

#!/bin/sh
{
    # Your stuff goes here
    exit
}

This ensures that all of your code is parsed initially; note that the 'exit' is critical to ensuring that the file isn't accessed later to see if there are additional lines to interpret. Also, as noted on the previous post, this isn't a guarantee that other scripts called by your script will be safe.

Thanks everyone for the help!