The application is connected in two ways: to bash, and to the terminal.
The connection to the terminal is that the standard streams (stdin, stdout and stderr) of the application are connected to the terminal. Typical GUI applications don't use stdin or stdout, but they might emit error messages to stderr.
The connection to the shell is that if you started the application with foo &
, it remains known to the shell as a job, as explained in Difference between nohup, disown and &. When you close the terminal, the shell receives a SIGHUP
, which it propagates to its jobs. When you type exit
in the shell, it disowns the jobs beforehand (this is configurable to some extent).
You can sever the shell connection with the disown
built-in. You can't sever the terminal connection, at least not without underhand methods (using a debugger) that could crash the program.
The fact that a process is "disowned" has only a meaning for the interactive shell that created this process. It means that the shell doesn't include (anymore) the process in its jobs table, and that SIGHUP will not be sent to this process when the shell exits. It is not really related with your questions.
About what happens to the outputs that are sent to a deleted virtual terminal: I made some tests myself, and I noticed that /dev/pts/x
devices are not accessible, and won't be allocated again until all filedescriptors that point to them have been closed. So, I can't see a reason why writes to a deleted terminal would be stored. I guess this is not even defined by POSIX.
About grabbing the output of some process that writes to a terminal, I don't think it is possible, even when the terminal is still alive¹. All you can do is grabbing the direct input to the terminal (i.e. keystrokes, or simulated keystrokes by the master part of a pty). If processes would read on stdin what is written to their terminals, that would lead to a self io loop for most process.
About the last remark on process termination, I don't really know what is happening, but I would suspect rather strange behaviors with signals (SIGTTOU, SIGTTIN, SIGHUP, or others) related to foreground/background state of process groups, when the session leader exits (e.g. su
, in the case you mentioned).
Answer to the Edit: No, with respect to output, nothing changes when a process is disowned: it is still attached to its controlling terminal (unless it detached itself already like daemons do). You can see that using ps
. However, you will not be able to use fg
/bg
/jobs
commands provided by the shell anymore for this process. That means it might be difficult to feed it with input from the terminal (requires to be in the foreground process group).
—
1. unless the process is willing to, or hijacked with some debugging tools (see comments above).
Best Answer
In general this should be fine to do it this way.
When you click the "X" to close the terminal window, that is sending a "signal" from your desktop (GNOME, KDE, etc.) to the terminal application, telling it to shut itself down. Since you're running MATLAB in this shell it's considered a child process to the terminal application.
So part of the responsibilities of being a parent process, is that you in turn send this same close "signal" to your children.
Now if you understand conceptually what I just explained then let's substitute in a bit more of the real terminology.
signals
First with the "signal", there are actually a whole family of different signals that you can send to Unix processes. To keep it simple there are 4 that you'll often see,
SIGHUP
,SIGTERM
,SIGINT
, andSIGKILL
.SIGHUP
SIGTERM
SIGINT
SIGKILL
NOTE:
SIGINT
is what gets sent when you use Ctrl+C to "break" a program from the command line while it's in the middle of running.which one is getting used?
Most likely the
SIGTERM
is being called by your windowing environment and being passed down to your terminal. Your terminal is then most likely then sendingSIGHUP
down to MATLAB. This signal gives all the processes the opportunity to do any local clean-up (closing files, ending processes, etc.) themselves.kill command
You can send signals yourself using the poorly named command,
kill
. So to send theSIGTERM
signal to your terminal or theSIGHUP to MATLAB, you could determine their PID using
ps` and then run this command to send them the signal:or this:
You can get a complete list of the signals using this command:
Notice that the signals have numbers? You'll often times see them used like that instead of by their names:
Or the infamous
-9
, which can kill pretty much any process.