vistatrio.blogg.se

1. INSTALLBUILDER RUN SHELLSCRIPT CODE
2. INSTALLBUILDER RUN SHELLSCRIPT PLUS
3. INSTALLBUILDER RUN SHELLSCRIPT WINDOWS

It turns out that once the current command has completed, Bash looks for the next character in the file to read.įor this test, I created another script, b.sh which is very simple, but easy to see where in its execution it is up to: This was actually the thing I was interested in when I started this investigation. Test Five: Copy a new file over the existing file But to any other process, the script has been modified. So the effect here is the same as in Test One above: The original script continues exactly as before. (use ls -il a.sh to check the inode of a.sh). This can be confirmed by checking the inode of a file as you edit it. When vim (or sed, or many other editors) edit a file, they actually save a new file and delete the original. When we display the script afterwards, we can confirm that it has modified itself: :~$ cat c.sh The script had appended the " date" command to itself, so at the end, it displayed the current date and time, even though that was not in the original script. This appends the word " date" to the script itself. Runs three echo commands, but one happens to echo "date" > c.sh.

INSTALLBUILDER RUN SHELLSCRIPT CODE

What happens if you append code to an already running script? Well, it gets read and executed, as if that had been there all along. "), but the loop continued until it had finished, then the echo "Interval" never happened, as if that had always been the way that the a.sh script had ended. In this case, I truncated the script whilst the loop was running (actually about when it was printing " 3. As above, the shell interpreter has the file open, but this time, when the currently-running command in the script has completed, the shell interpreter then finds that there are no more commands to read from the script, and it exits, with a return code of zero.

It is possible to truncate a file that is, it is the same file, it keeps its inode number, ownership, permissions, etc, but its contents are removed.

The output is exactly like that shown above. As a result, the shell script kept on running until it had completed normally. The shell interpreter had the file held open, so the kernel does not actually delete the file from the disk until that shell process closes it. :~$ Test One: Delete a running scriptįor my first test, I deleted a script which was running. Then it does another sleep, then echo "Interval.". (note: the first sleep really should have been indented to match the echo -n above it.) This is relevant because although it traverses many lines, the entire for loop is one command, as far as the shell is concerned.

INSTALLBUILDER RUN SHELLSCRIPT PLUS

The main script is a simple little loop, plus a few other commands: The first terminal ran the script, the second terminal did something to modify it.

INSTALLBUILDER RUN SHELLSCRIPT WINDOWS

To do the tests, I opened two terminal windows on a GNU/Linux laptop. Some of these observations are more about the kernel and Unix/Linux's treatment of open files, but it is all informative. It might be interesting to repeat these tests with other shells and filesystems. For reference, the shell used for this is Bash (version 4.3.30) on an ext4 filesystem. For this test, I created some small shell scripts and observed what they do under different conditions. It turns out that there isn't one single answer to this, as it depends on how you make the change. I realised recently that I wasn't confident in my understanding of what happens when you change a shell script which is already running.