I've written a simple Bash script -- actually two interdependent scripts -- to serve as a simple timer -- mostly so I don't forget that I've started a cup of tea in the kitchen while I get absorbed in whatever's on the computer screen.

The first script ("timer") is simply a series of error-checks, to make sure I've included the right number and type of argument: an integer followed by either an s (for seconds) or an m (for minutes). For example will set the timer for five minutes.

If those tests are passed, the final line calls the second script (timer-run), passing the same arguments it received and sending that second script to the background, like this: The timer-run script uses a sleep command to do the actual timing, then sends within a for-loop to ring the system bell a few times (with a one-second sleep command between the iterations) to let me know the tea (or whatever I've been timing) is ready.

All this works very well, if that's all I ask it to do. However, if I'm away from the computer when the bell chimes, I may not hear it. I've added a simple text output right after the last ring of the bell, sending something like "Time's up!" to the screen.

The message goes to the screen, no problem. However, when that's done, and control is returned to me, no CLI prompt is displayed on the screen. I can type a new command of any sort and get the appropriate result, and the prompt returns once that new command is finished, so there's no real problem in execution.

But I don't understand what's going on that skips the part about showing the prompt after a background program sends an echo to the console and exits. And I'd like to know if there's anything I can add to my script to make the prompt show up.

The prompt is issued by the shell, presumably bash, in response to entry of a command. Your script is merely using the console as it's destination for it's standard output. The shell doesn't know that text was sent to the console; your script is no different from any other program that uses the console as standard output, in that sense. The fact that the data is sent to the console asynchronously while your script is backgrounded isn't relevant, although I can sort of see how one might think it should be.

I don't fully understand this, theNbomr. If I edit the "timer" script so that it calls timer-run without the trailing ampersand, i.e. simply as: . . . then the CLI prompt is suspended until the program finishes and the bell has chimed, then the prompt returns. But with the appended ampersand, the program finishes, the bell chimes, and no prompt appears, so how can it be unrelated to the fact that my program's running in the background?

That's less important, actually, than learning whether or not there's some way to make the prompt appear. I thought I might be able to add something to the script to bring it into the foreground, say, for example but I can't figure out a way to get the job-number into the script, so I can't even know if that would work or not.

"How many computer program(mer)s does it take to burn a cup of tea?"

I have a nice egg-timer, which looks like a little wooden egg. (P.S. it doesn't run Linux.)

That's not possible, don't lose time with this.
And it's not a good idea to echo some text to the console from within a backgrounded script. Don't do that.
Cheers.

Well, I'm not spending a great deal of time on it. The function, per se, is not all that important. I primarily wrote it -- and continue to explore the implications of its behavior -- as a way of further exploring Linux, the Bash shell, and script-writing. It's part of my learning process.

So, for example, from the first response I can kind of get an idea why the prompt doesn't reappear. Then this last reply raises another question, to wit: why is it not a good idea to echo text to the console from a background process? And why is it not possible to return that background process to the foreground (if that was, indeed, what was meant)?

When a background process writes to the screen, it corrupts the display of whatever is going on in the foreground. You might be scrolling through a file using less or perhaps just typing a command into a shell, then the background process displays some text and causes the foreground process to lose track of what is on the screen and where the cursor position is. It's not terrible (there's usually some way to make the foreground process refresh its screen), but it's an annoyance if it happens often.

A background process cannot move itself back into the foreground. That is something that only the foreground process that spawned it can do -- relinquish control of the terminal and wait for the process to complete. The big issue is control of the terminal. Very bad things happen when you have two processes trying to use the terminal interactively -- reading input, setting modes, etc. On occasion, you need to go to another terminal and kill processes to get out of that.

BTW, my own "egg timer" process creates its own window and runs in that. No interference.

Thank you, rknichols. That is very clear and very helpful.

The prompt appears when the program you launch returns control to the shell. In the case of backgrounded processes, that occurs as soon as the process is launched, rather than after the program exits.