I am making a bash script for Linux which closes the terminal window if the window loses focus.

On the command line, I was able to do this:

termwin=$(xdotool getactivewindow)

while : 
  if [[ $(xdotool getactivewindow) != $termwin ]]

It works typed manually into a terminal, but, if I put it into a script, instead of closing the window when focus is lost, the script simply stops. No error or anything, just back to a prompt.

I feel like I'm missing something basic.


After reading this...: See here

I tried running this as ". test.sh" rather than "./test.sh" and it worked. The link describes the difference in these methods as running the script as a subprocess or as part of the main process, respectively. Can anyone just explain this, and/or modify the script to run successfully with "./" instead of ". ", in the latter creates issues?

  • shell script debug is my fun, hold on, I shall try to reproduce. I know xdotool its an automate tool. – Rony May 16 '12 at 16:08
  • My idea is a bit off-topic: do you know about "exotic" window managers? E.g. awesome (awesome.naquadah.org) - you can do this or similar functions easily. – uzsolt May 16 '12 at 16:35
  • @uzsolt, you are to? if me, I am mainly on awesome wm quite some years and now and all. – Rony May 16 '12 at 16:40
  • Yes :) In awesome this is only about 3 lines :) In bash... – uzsolt May 16 '12 at 16:47
  • @uzsolt dear, awesome wm has lua, homebrew widgets are candies :), bashlets is another playground :) – Rony May 16 '12 at 16:57

When you source the file with ., the commands will run just as if you had entered them in the command line. Thus exit will exit your currently running shell.

To exit the shell from which the script was executed when forking, you need to get the process id of the parent process. You can try running

kill ${PPID}

in the script instead of exit to kill the parent shell (tip: try just echoing the pid first and check which process it corresponds to so you don't kill your WM or something).

If ${PPID} doesn't do it for you, you can also try sending the pid as a parameter to the script, but it depends on how and where it's called.

You said you used urxtvd/urxvtc. With that combination, this script kills the terminal from which it was started:

echo kill in 3
sleep 3
kill -1 ${PPID}

so you should be able to use kill -1 in this way to kill a single urxvtc instance.

Note that if you run this by sourcing, then the urxvtd instance will be $PPID for the currently running terminal, and all terminals will die. You don't want that.

  • Dan, the kill PPID method looks good, but fails with my particular terminal. Im using urxvt in a client/daemon setup (urxvtd and urxvtc). It seems that each terminal in this case has the same ppid, and s =o this method doesn't work. What is different is the pty, as found with the tty command. You can directly tell a pty to do something, right? Something like (not working) "exit >>/dev/pts/0" – Fruckubus Crunt May 16 '12 at 19:34
  • @FruckubusCrunt: Each terminal has the same PPID (parent pid), but when you launch a script from a terminal, inside the script the launching terminal's pid will be PPID, so it sends the signal to the correct pid. However, -1 seems to be needed with urxvtc. I'll update my answer. – Daniel Andersson May 17 '12 at 12:06
  • This is great Dan, thank you. A good learning experience for me. And I certainly could not accept a situation where more terminals would die, as that would defeat the purpose of what I'm doing. So thanks for the solid explanation. – Fruckubus Crunt May 17 '12 at 14:21

Hope the script will work as needed:


termwin=$(xdotool getactivewindow)
while : ; do
    [ $(xdotool getwindowfocus) = $termwin ] || kill -9 $PPID
  • This yields the sme results for me, it works if typed in manually, and fails – Fruckubus Crunt May 16 '12 at 17:32
  • I am now wondering if "exit" is the problem. Typed into a terminal, 'exit' closes the terminal, but is it possible that "exit" has a different meaning in a script, that stops the script rather than closing the terminal? Or is this even possible? – Fruckubus Crunt May 16 '12 at 17:48
  • Please see edit. – Fruckubus Crunt May 16 '12 at 18:02
  • Refrain from using kill -9. A single kill is enough, and much nicer. kill -9 does nothing nice. – Daniel Andersson May 17 '12 at 11:58
  • @DanielAndersson thank you very much for your refreshment and very useful link. I use the -9 because my kill does not kill. I shall look into the matter. – Rony May 17 '12 at 12:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.