Technology Tales

Catching keyboard interruptions in a Python script for a more orderly exit

17^th April 2024

A while back, I was using a Python script to watch a folder and process photos in there, whenever a new one was added. Eventually, I ended up with a few of these because I was unable to work out a way to get multiple folders watched in the same script.

In each of them, though, I needed a tidy way to exit a running script in place of the stream of consciousness that often emerges when you do such things to it. Because I knew what was happening anyway, I needed a script to terminate quietly and set to uncover a way to achieve this.

What came up was something like the code that you see below. While I naturally did some customisations, I kept the essential construct to capture keyboard interruption shortcuts, like the use of CTRL + C in a Linux command line interface.

if __name__ == '__main__':
    try:
        main()
    except KeyboardInterrupt:
        print('Interrupted')
        try:
            sys.exit(130)
        except SystemExit:
            os._exit(130)

What is happening above is that the interruption operation is captured in a nested TRY/EXCEPT block. The outer block catches the interruption, while the inner one runs through different ways of performing the script termination. For the first termination function call, you need to call the SYS package and the second needs the OS one, so you need to declare these at the start of your script.

Of the two, SYS.EXIT is preferable because it invokes clean-up activities while OS._EXIT does not, which might explain the "_" prefix in the second of these. In fact, calling SYS.EXIT is not that different to issuing RAISE SYSTEMEXIT instead because that lies underneath it. Here OS._EXIT is the fallback for when SYS.EXIT fails, and it is not all that desirable given the abrupt action that it invokes.

The exit code of 130 is fed to both, since that is what is issued when you terminate a running instance of an application on Linux anyway. Using 0 could negate any means of picking up what has happened if you have downstream processing. In my use case, everything was standalone, so that did not matter so much.

Keep a hold on those serial numbers…

3^rd August 2007

In the times when all software was bought boxed, there were fewer issues with finding serial numbers, activation codes and the like. If you were tidy and retained the packaging and documentation while knowing where to find them, you were away. However, in these days of software distribution over the web, things are a little less clear-cut. The said codes tend to reside in emails sent following the purchase and, if you are like me, they tend to be scattered around the place; it is not a good thing when you need to get your software reinstalled after a system meltdown, like what I am needing to do. Another trap is that expensive software could disappear all of a sudden if your hard drive crashes, not an enticing thought. A spot of backup of both the installer and product key seems very much in order.