Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

Suppose I have a script script.sh, which takes some time to execute. I execute it, ./script.sh. While it is running in a terminal window, I modify the file script.sh. Will this have any effect on the already running process?

After modifying it, I execute the modified file, so I have two running process now. Is this okay?

share|improve this question
2  
similar to unix.stackexchange.com/q/121013/55673 on U&L –  Registered User Jun 16 at 14:30

3 Answers 3

up vote 26 down vote accepted

When you make changes to your script, you make the changes on the disk(hard disk- the permanent storage); when you execute the script, the script is loaded to your memory(RAM).

So, the changes that you make to the script will not affect the running script, it will run the version you executed before making those changes.

However, when you execute the changed script again without terminating the previously running instance, there will be two instances of the script- one which has the changes and the old one.

Be warned that the resources that the script uses and modifies will conflict. For example, if you are modifying a file using the script, the script that runs later will not be able to open that file for writing and fail to execute correctly.

Update: Thanks to Registered User for pointing me to a better answer on Unix.stackexchange.com.

Depending upon the size of the script and the compiler/interpreter in question, the script is loaded partially/completely. So, if the script is not completely loaded, the changes that you make to your script will reflect on the running instance once the part of the script is loaded into memory.

So, it is not recommended to change your script on the disk which is currently running for unpredictable output: First stop the running instance and then modify your script and then re-execute the script.

share|improve this answer
    
+1 Just the answer I was expecting. Thanks. –  becko Jun 16 at 14:25
8  
Not the perfect answer, read unix.stackexchange.com/q/121013/55673 –  Registered User Jun 16 at 14:30
    
@registereduser: oh yes, that question just reminded me of my OS lessons. Will edit my answer as soon as i get my hands on to my desktop (on my phone right now) –  i08in Jun 16 at 14:38
    
I guess that for short scripts there should be no problem. –  becko Jun 16 at 15:49
1  
@RegisteredUser Not with all versions of bash -- see the example I linked. –  Gordon Davisson Jun 17 at 5:04

I'll add something that I think has not been said in the other answers. Much depends on just how you edit the file. Doing echo "stuff" >file from the shell (another instance) will indeed overwrite the file, I think. But if you edit the file with for instance emacs and then save, this will not happen. Instead here the editor renames the old file to some backup name (maybe actually removing the previous backup), and then write its modified buffer contents as a new file with the (now libreated) old name. Since the shell (or other interpreter) reading the script will almost certainly open the file only once, it is thereafter independent of the whereabouts of the file name, it just continues to read the physical disk file (identified by inode number) that was associated to the file name at the time of opening. So even if it reads the script in blocks (which would be the easiest solution if using buffered text I/O), it would continue to read the lines from the old instance of the file, which is likely to not change by your editing.

share|improve this answer
    
+1 I am using Sublime Text as my editor. Do you know if it too renames the file, like emacs? –  becko Jun 16 at 17:03
1  
I think most editors would use a renaming scheme (even if they should not keep backup versions) to avoid the risk that if a crash happened during the write process, no intact version of the text would remain at all. You can check with "ls -i" (which shows inode numbers) what the behaviour of your editor is. –  Marc van Leeuwen Jun 17 at 3:48

@jobin's answer is generally correct, but I'll add some other answers that may be to the point depending what you want to do.

If you want to change the script, and want to know that it's safe, then you want to write to a new file, not the existing one, The new file can be located where the old one was though. Write your new version to a new file, and then use mv to move it into place over the top of the old one. The file that has been replaced still exists, it's just not linked from the directory. Your running script can continue using it, and when that script closes its file handle the system knows that it can safely clean up the file (whether immediately or at a later time).

If you want to behave the behaviour of the script on the fly, you have a more difficult problem. I expect you'd need to build it into the code of the script. Bash scripts can handle signals (eg can catch something like kill -USR1 [pid]), and a script could then respond by reloading some code. So maybe you can get functionality close to what you want, but without knowing what you're after, I'm not seeing a good reason to do this, and I suspect if you want to do something this complex you probably want a more sophisticated programming language to do it in.

If you want to hack the behaviour of a running script that is not written with this in mind, then you're out of luck. I'd hesitate to call any programming task impossible, but if you had the resources and skills for this sort of task, you presumably wouldn't be asking here.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.