On Wed, Sep 17, 2025 at 17:31:04 +0200, pourko--- via Bug reports for the GNU Bourne Again SHell wrote: > Nothing interactive in that. Now, if some other script, > that calls my script, were to spin it off with an "&", that's when > one of my functions gets stuck there forever. I am trying to find a > way for my functions to detect such condition and avoid getting stuck.
When a program running in the background tries to read from the terminal, it gets smacked with a SIGSTOP. Consider this script: hobbit:~$ cat x #!/bin/bash printf 'What is your name? ' read name printf 'Hello, %s!\n' "$name" If I run this as a foreground program from a shell inside a terminal, it does exactly what you'd expect. But if I run it in the background, it gets stopped. hobbit:~$ ./x & [2] 1365825 hobbit:~$ What is your name? Human bash: Human: command not found [2]+ Stopped ./x hobbit:~$ This is just how background jobs in terminals work. They can write to the terminal as much as they like, but they can't read from the terminal. Now, this is where I get confused about your goals. It sounds like you've written a program that interacts with a user via the terminal. If something else runs your program as a background command, then your program won't work. It'll be stopped when it tries to read the user's responses from the terminal. In that situation, the error is not in your program. It's in the other program that tried to run an interactive process in the background. It's not your *job* to work around the errors in other programs. That way lies madness.
