Shell Programming and Scripting

Hello All,

Greetings !!

I have a query here to all is as follows:

Question: Let's say we are running a script in a UNIX box and we have opened an another session and then made changes in script of some statements NOT to be print some values(just an example) so when I am monitoring the other session changes didn't reflect, so my question is after running a script:

i- Seems script will be loaded to RAM(MEMORY of UNIX) from where it is picking the script?
ii- So after script's completion only changes will be picked which we made after running the script?
iii- Is there any way if above 2 points are valid like we can make changes while a script is running and can be shown within same run of UNIX script?

Will be grateful to you, if someone can put some light on this, I am sorry if this is a basic/dummy question but I faced this, so thought to share with all and get people's view/comments on same.


Thanks,
R. Singh

Changing any program while it is running (C, C++, FORTRAN, ... a.out), awk script, or shell script) might have absolutely no effect (the program was loaded when it started and runs from memory independent of the contents of the file(s) it was loaded from), or might cause it to die a horrible death when a block of memory containing commands being processed changes into something else that might be a mix of characters that don't quite make up the new program or the old program. Specifying when something will continue working unchanged may vary depending on the OS, the shell, the filesystem type from which the program is loaded, whether it is a statically linked binary, a dynamically linked binary, or an interpreted language, whether or not the sticky bits that way), and lots of other conditions.

If you have a separate script that you invoke when you want to produce output after lengthy computational loops in a script, and you change that separate script while the base script is performing one of those lengthy computations; you might get what you want. If you try to change the text of a function that has already been loaded by the shell, later invocations of that function aren't likely to be affected by changes to the source for that function. But if modifying that function at the start of your shell script changes the length of the script and your script consumes more than one block on disk, your script could die when it loads the next block of the script and finds that the command that crossed the boundary between two disk blocks duplicated or dropped a few characters, all bets are off.

Although you might be able to figure out what will happen to you on a particular version of an OS and shell combination, there is no guarantee that the same thing will happen after you upgrade to the next update of that OS or shell.

Mostly you might want to input/output something from the script. I don't suppose you want to change the logic of your script during run-time. You could use a file to read/write data and allow the script to pick up values from the file.

A long script does not read everything in advance.
Then unpredictable things happen when it continues reading the suddenly changed script.
I suggest to create a new script first, then use mv to replace the old script. Running scripts will continue to read from the old script. This should also work with NFS (where the removed script is renamed .nfsXXXXXX) .

What is the definition of a long script?
Me have a (still not working) build script for ffmpeg, beeing a medium (compared to most of my scripts that are scripts and not just command as 'tui-XY') length script of aprox 700 lines.

But then there is VHS, which will become the (my) largest one with 3400 lines once the ffmpeg-build script works and is included. (currently ~2700 lines).
Is that a long script already?

I know (from this forum) of people having scripts with like 20k or even 30k lines.
For those script i'd choose the suggestion of MIG, but for other reasons, as the larger the script, the higher the chance a typo can break everything.

The definition of a long script in this context is a file that contains more bytes than the shell reads in a single read() system call when reading your script. That number can vary from shell to shell (where an update to a given shell counts as another shell) and may vary with the block size of the filesystem from which the script is being read. For most shells I've seen it is somewhere between 512 bytes and 20kb (but I haven't looked at any shell source for several years).