On 05/17/2017 09:50 AM, gregrwm wrote: >> >> i was shocked to discover that killing a window (in tmux) does not kill >> the bash procedure running in it. how would you recommend that a bash >> function check whether it's output is visible anywhere anymore? >> > > i've had a chance to poke at it a bit now, all the simplified test > functions i try all *do* exit with their parent window, even tho i include > many of the structural elements of the full function. the full function > however does not exit with the window. dunno why, tho it doesn't really > matter.. to answer my own question: > > [ -t 1 ] > > nicely tests if the parent terminal still exists, or, since the function > invokes "less", i can simply use the abnormal exit from less as an > indication the terminal is gone. FYI As a general rule, closing a terminal window will send a SIGTERM signal to the shell, and close resources controled by the window. e.g. stdin, stdout, stderr, /dev/pts/... etc... So your child process will usually either catch the SIGTERM, or detect that it's /proc/self/fd/* references have been closed and terminate itself. But there are some cases where the child process ignores signals and doesn't check the status on it's resources. So it closed stdin itself and no longer listens for input, or only accesses stdout/stderr if needed. In those cases the child process could run until it attempts to access those resources and terminates with an error accessing them in the future. An example of this that I use is a backgrounded ssh port forward: "ssh -L 1234:target.host:22 -N pivot.host &" I've had these last though complete logouts, which I like, until I really want it to terminate and need to run netstat -lnp to find it again. Hope that clears things up a little.