3

I ask because I recently made a change to a KornShell (ksh) script that was executing. A short while after I saved my changes, the executing process failed. Judging from the error message, it looked as though the running process had seen some -- but not all -- of my changes. This strongly suggests that when a shell script is invoked, the entire script is not read into memory.

If this conclusion is correct, it suggests that one should avoid making changes to scripts that are running.

$ uname -a
SunOS blahblah 5.9 Generic_122300-61 sun4u sparc SUNW,Sun-Fire-15000
javaPlease42
  • 4,699
  • 7
  • 36
  • 65
Kirby
  • 704
  • 4
  • 7
  • This question may be duplicity of [already answered question](http://stackoverflow.com/questions/3398258/edit-shell-script-while-its-running). – LRA Aug 03 '13 at 15:54
  • 2
    Shell scripts are read in blocks, so if there's a big loop, then all the material for the loop will be read, but material beyond may not have been processed. I've certainly seen changes to a shell script while it was running cause problems — avoid it. But it doesn't always happen and depends on the shell, platform and maybe script. It might also be affected by 'block size'; the shell might easily read the file in blocks, stopping when it no longer needs to read more for the time being. – Jonathan Leffler Aug 03 '13 at 15:59
  • 1
    @Jonathan: the assertion that shell scripts are read in blocks fits with my experience and would explain why the executing script picked up an incomplete version of my changes. – Kirby Aug 04 '13 at 01:12

3 Answers3

1

No. Shell scripts are read either line-by-line, or command-by-command followed by ;s, with the exception of blocks such as if ... fi blocks which are interpreted as a chunk:

A shell script is a text file containing shell commands. When such a file is used as the first non-option argument when invoking Bash, and neither the -c nor -s option is supplied (see Invoking Bash), Bash reads and executes commands from the file, then exits. This mode of operation creates a non-interactive shell.

You can demonstrate that the shell waits for the fi of an if block to execute commands by typing them manually on the command line.

http://www.gnu.org/software/bash/manual/bashref.html#Executing-Commands

http://www.gnu.org/software/bash/manual/bashref.html#Shell-Scripts

Alex W
  • 37,233
  • 13
  • 109
  • 109
  • No, they’re usually read in blocks that depend on the input buffer of the shell in question, for example, 128 bytes in one go. – mirabilos Sep 17 '13 at 11:54
  • Sure, they're read in blocks, but shell is top-down imperative, meaning it looks for control structures to see whether it should continue. So it may have read the next `$BUFSIZE` bytes from the file, but if it sees a newline and `exit 255`, it's going to bail out. You're both right. – jane arc Oct 23 '13 at 17:55
0

It's funny that most OS'es I know, do NOT read the entire content of any script in memory, and run it from disk. Doing otherwise would allow making changes to the script, while running. I don't understand why that is done, given the fact :

  • scripts are usually very small (and don't take many memory anyway)
  • at some point, and shown in this thread, people would start making changes to a script that is already running anyway

But, acknowledging this, here's something to think about: If you decided that a script is not running OK (because you are writing/changing/debugging), do you care on the rest of the running of that script ? you can go ahead making the changes, save them, and ignore all output and actions, done by the current run.

But .. Sometimes, and that depends on the script in question, a subsequent run of the same script (modified or not), can become a problem since the current/previous run is doing an abnormal run. It would typically skip some stuff, or sudenly jump to parts in the script, it shouldn't. And THAT may be a problem. It may leave "things" in a bad state; particularly if file manipulation/creation is involved.

So, as a general rule : even if the OS supports the feature or not, it's best to let the current run finish, and THEN save the updated script. You can change it already, but don't save it.

It's not like in the old days of DOS, where you actually have only one screen in front of you (one DOS screen), so you can't say you need to wait on run completion, before you can open a file again.

tvCa
  • 796
  • 6
  • 13
0

No they are not and there are many good reasons for that. One of the things you should keep in mind is that a shell is not an interpreter even if there are some similarities. Shells are designed to work with a stream of commands. Either from the TTY ,a PIPE, FIFO or even a socket. The shell reads from its resource line by line until a EOF is returned by the kernel. The most shells have no extra support for interpreting files. they work with a file as they would work with a terminal. In fact this is considered to be a nice feature because you can do interesting stuff like this How do Linux binary installers (.bin, .sh) work?

You can use a binary file and prepend shell scripts. You can't do this with an interpreter. because it parses the whole file or at least it would try it and fail. A shell would just interpret it line by line and doesnt care about the garbage at the end of the file. You just have to make sure the execution of the script gets terminated before it reaches the binary part.

minzchickenflavor
  • 496
  • 5
  • 17