It ultimately depends on the program.
When running, all programs will block the terminal until they finish running, or until they are manually stopped using ctrl+c - or killed from another terminal via the kill command.
This is especially the case with daemons, which typically run perpetually. That's probably what you're experiencing here with whatever daemon you are running in the terminal.
With things like daemons - if you don't want the terminal to be blocked until they are finished, then what you do is run the daemon in the background by appending an & at the end of the command.
somedaemon --option1=value1 --option2=true &
Above is a completely contrived example - we start somedaemon, passing some parameters and using an & at the end to run it in the background.
When running a process in the background - you will be able to continue to use the terminal and enter other commands/run other programs.
But any time the daemon outputs something to stdout - it will end up being echoed in the terminal that started the process.
So you might occasionally get interrupted by some messages from the daemon.
One way around that would be to redirect all of the output of the daemon to a file.
somedaemon --option1=value1 --option2=true &> /path/to/some/logfile &
The &> redirects stdout and stderr to the specified log-file.
Or you could completely ignore the output from the daemon by redirecting it to /dev/null:
somedaemon --option1=value1 --option2=true &> /dev/null &
That way all output from the daemon is hidden.
Also - whenever you start a process in the background, the terminal will display the Process ID (PID) of the process.
You can also use the bash's
builtin command to see any background processes that the current terminal is running. Using the
parameter with jobs shows the PIDs of the processes along with the usual information (handy in case you forget the PID of the job you started in the background).
To see all of the options available for the
command, use the command
Additionally, you can use the
command to send signals to processes in order to kill them, or stop/resume them.
Sometimes terminal based programs do stop and wait for input.
For example some programs expect input from a file. And if they don't receive a path to a file in their parameters - they will use stdin as the input file.
So, in lieu of input from a file - these types of programs will continue to process anything you type on the keyboard until you hit a key combo like CTRL+D - the end of file key-bind, or CTRL+C - which typically kills the program, or CTRL+Z, which suspends the program.
If you suspend a program with CTRL+Z - it will be paused/suspended and listed by
as a stopped process.
To resume the process in the foreground, you can use the
To resume the process in the background, you can use the
command (though, restarting a process in the background is really NOT a good idea if the program expects interactive input from the user!).
And again - the kill command can be used to send signals to the process, in order to control its execution, or kill the process.
Hopefully that all makes sense and is useful to you!