[SOLVED] No CLI prompt after background process prints message to screen and exits
Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
No CLI prompt after background process prints message to screen and exits
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
timer 5 m
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:
timer-run 5 m &
The timer-run script uses a sleep command to do the actual timing, then sends
echo -en "\x07"
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:
timer-run 5 m
. . . 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.
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.
Last edited by rknichols; 03-30-2014 at 10:17 AM.
Reason: Add "BTW..."