I've been writing code for a long time but I can't say that I've ever encountered this until today...

I have a bash script that reads large datasets and extracts information out to a files that I'll be converting to a different format later. I kicked off the script a while ago and, while it was running, decided to edit the script and add
to the very end so I would know when it was done. (It can take maybe 10 minutes to run so I'll multitask while it's grinding away.) At least, I thought, on the next run I'd get an audible indication that it was done and I could go on to the next run.

The weird thing is that the audible announcement came at the end of the run that was in progress -- and not yet completed -- when I finished with the edit to the script.

I would expected that the run in progress would complete silently and that the mplayer line would not have been "seen" until the next time the script was run.

Has anyone else noticed this?

The seems to be a new behavior. It looks like I'll need to be careful when making edits from here on.

I don't think that's unusual at all.

If the long-running process runs in a sub-shell, the script you were editing was just waiting for the sub-shell to return to it.
When it did, it continued and included the new code you'd added and saved.

Well that does make some sense. The script is a wrapper for a C program---the part that does all the heavy lifting. I would have expected some caching to have taken place so that the script that running had already been read and the disk copy wouldn't be touched again until it was re-run.

I suppose having shifted to mainly Perl scripts years ago (and, recently, to Python) I've gotten used to the way they execute. There have been many instances where I ran a lengthy Perl script, saw something goofy about a messages it was issuing, decide those were not quite what I wanted, and decide to edit the script right then. Never do I recall seeing the revised messages appear until the next time the script was run.

I think this harkens back to a discussion thread a little while ago about compiled vs. interpreted languages. I guess this experience is indication that shell scripts really do get read a line at a time and that the main bash process is keeping track of what line it's on before going back to the disk image and reading the next line. Probably easy to test this (though maybe later).

Now I'm off to consider what sort of crazy things you could do with self-modifying shell scripts. :^D

Cheers...

An strace of your script might be enlightening -- to you, that is.
I'm not suggesting you post it

If you're using a window manager with, dang, I forgot the name for it, alerts? Like, xmonad, which I am using, has the option to point out a workspace and window in which an event has happened.

If you are using such a window manager, then you could change the PS1/Status of your shell to always add a bell to it, so background terminals will alert you when they're done.
I have this in my zshrc, for example
My audio bell is switched off, or I'd probably be annoyed, but otherwise I have grown to really like this.
Usually, WMs are smart enough to not nag you when the window is focused already, too. So, that's a nice bonus.

Edit:
To clarify:
The idea is to change the terminal prompt to add the bell character to it, which does not get printed, it just triggers the bell.
Since the prompt is given every time a task is completed, to, well, prompt for further input, you will therefore get a bell when a task is completed.
That way you'll always know when a background job is done, no matter how big or small.

Bash compatible way :
https://superuser.com/questions/2756...questions-read