Prevent a console app from closing when not invoked from an existing terminal?

Question

There are many variants on this kind of question. However I am specifically after a way to prevent a console application in Python from closing when it is not invoked from a terminal (or other console, as it may be called on Windows). An example where this could occur is double clicking a .py file from the Windows explorer.

Typically I use something like the following code snippet, but it has the unfortunate side effect of operating even if the application is invoked from an existing terminal:

def press_any_key():
    if os.name == "nt":
        os.system("pause")
atexit.register(press_any_key)

It's also making the assumption that all Windows users are invoking the application from the Windows "shell", and that only Windows users can execute the program from a location other than an existing terminal.

Is there a (preferably cross platform) way to detect if my application has been invoked from a terminal, and/or whether it is necessary to provide a "press any key..." functionality for the currently running instance? Note that resorting to batch, bash or any other "wrapper process" workarounds are highly undesirable.

Update0

Using Alex Martelli's answer below, I've produced this function:

def register_pause_before_closing_console():
    import atexit, os
    if os.name == 'nt':
        from win32api import GetConsoleTitle
        if not GetConsoleTitle().startswith(os.environ["COMSPEC"]):
            atexit.register(lambda: os.system("pause"))

if __name__ == '__main__':
    register_pause_before_closing_console()

If other suitable answers arise, I'll append more code for other platforms and desktop environments.

Update1

In the vein of using pywin32, I've produced this function, which improves on the one above, using the accepted answer. The commented out code is an alternative implementation as originating in Update0. If using pywin32 is not an option, follow the link in the accepted answer. Pause or getch() to taste.

def _current_process_owns_console():
    #import os, win32api
    #return not win32api.GetConsoleTitle().startswith(os.environ["COMSPEC"])

    import win32console, win32process
    conswnd = win32console.GetConsoleWindow()
    wndpid = win32process.GetWindowThreadProcessId(conswnd)[1]
    curpid = win32process.GetCurrentProcessId()
    return curpid == wndpid

def register_pause_before_closing_console():
    import atexit, os, pdb
    if os.name == 'nt':
        if _current_process_owns_console():
            atexit.register(lambda: os.system("pause"))

if __name__ == '__main__':
    register_pause_before_closing_console()

Capitulum

Instead of os.system("pause") you can use sys.stdin.read(1) which works on all plattforms. – Orvilleorwell

@tux21b: this only works if stdin is set to unbuffered – Capitulum

This doesn't work now since Python 3 started to use py.exe launcher: wndpid is py.exe's PID, and curpid is python.exe's PID. – Janitor

Any solution available which works with new Python 3 py.exe launcher? Thanks! – Feudality

Answer 1

First, an attempt to disuade you from clever hacks. It's perfectly appropriate to have a seperate shortcut designed to be run from Explorer that does slightly different things (like holding the console open) from the script to be used from the commandline. As Alex has already pointed out, this is not an issue on nix, and the right thing to do there is always exit cleanly or your users will complain.

If you still want a workaround, here's code to detect when the console needs to be prevented from closing that's reasonably clean. Requires Windows 2000 or later, the logic is contained in this function:

def owns_console():
    wnd = GetConsoleWindow()
    if wnd is None:
        return False
    return GetCurrentProcessId() == GetWindowThreadProcessId(wnd)

Basically, it gets the PIDs of the process that owns the console Python is using, and of our process. If they are the same, then when we exit the console will go away, so it needs to be held open. If they are different, or if there's no console attached, Python should exit normally.

Transitive

+1 for noting that it is obnoxious to do that kind of thing on UNIX. – Avis

Your link has died. Do you know another spot where the info could be found? – Redneck

Fixed the link. – Transitive

Answer 2

On Unix, sys.stdin.isatty() reliably tells you whether standard input is coming from a terminal-like device (or is otherwise redirected), and similarly for the same method on sys.stdout and sys.stderr -- so you can use those calls to determine whether the application is being executed interactively or in some non-interactive environment (such as a cron job). Exactly how you want to use them depends on what you want to do if (for example) both standard input and output are redirected to a non-terminal but standard error is going to a terminal -- consider each of the 8 possibilities, from all of them redirected to non-terminals to none of them, and decide what you want to do in each case.

On Windows the situation is different since executing a .py file (as opposed to a .pyw file) will create a new transient console (there's no exactly equivalent situation in Unix); I assume that's the case you want to deal with? (Or is it just about redirection of standard I/O streams to files, which is possible in Windows roughly just like in Unix?). I think the best approach in Windows might be to use win32api.SetConsoleCtrlHandler to set a handler for such events as CTRL_CLOSE_EVENT -- this way the handler should be invoked (in this case, when the console closes) if there is a console for the process, but not otherwise. Or, if all you care about is whether a console is there at all or not (and prefer to handle things your way otherwise), try calling win32api.GetConsoleTitle in the try leg of a try/except statement -- it will generate an exception (which you catch and respond to by setting a boolean variable of yours to False) if there's no console, and just work (in which case you set that boolean variable to True) if there is a console.

Osteoporosis

in my case, execution from windows shell, or from existing terminal returns True for isatty() on all standard streams. furthermore, handling of the console ctrl events arrive after process termination. the subsystem in use is definitively console, not windows, for this application. – Capitulum

@Matt, so use the GetConsoleTitle in a try/except idea -- have you tried that? – Osteoporosis

A console is present regardless, so GetConsoleTitle() will always return. I've generated a reasonable function from it's return value however, I'll put it in my question. – Capitulum