isatty() not working via ssh, or on OS X?

[Nigel]

The FindDatabase() and database schema upgrade code tries to work out if it is run from an interactive console, and if so, prompts the user for values. Ticket #9174 reported that this no longer works on Mac OS X, but it definitely used to work when I wrote the code — I think the failure is due to mythbackend's main.cpp now doing this:

    ///////////////////////////////////////////////////////////////////////
    // Don't listen to console input
    close(0);

for some reason I don't understand.
Either way, failing to work in an ssh shell is still a problem.

[Github]

Re-enable early console interaction in mythbackend. Refs #10090

Verified both fault and fix on Linux and Mac OS X. (Windows? Meh!) main() was closing stdin before the database is selected or the schema is potentially upgraded. Commit 064931c34f somehow missed moving this.

Branch: master Changeset: 888a9849ce8f78a7422ee9022d39ed8c9af4b706

[Github]

Fix interactive shell check.

Reverts 888a9849c and fixes #10090 with a different patch.

The original fix in 888a9849c broke database upgrades for users who start mythbackend in a terminal with the -d/--daemon argument (but DB upgrades worked for users who started mythbackend in a terminal without the -d argument, or who started mythbackend in a script with the -d argument).

The problem is that moving the close(0) to after the SchemaUpgradeWizard? caused getResponse()'s isatty(fileno(stdin)) check to return true. However, by this time, we had already daemonized the application, so the terminal no longer sends keyboard input to mythbackend (not properly, at least--keyboard input seems semi-broken until mythbackend is shut down/killed), and the cin.getline(response, 80); hangs, forever, waiting for the user to type yes or no in response to the question, "Shall I upgrade this database? [yes] no". The user does see the question in the terminal, but if they type "yes", the input goes to the shell, which runs the *nix "yes" command in the foreground--which then prints a billion y's to the terminal. :)

This fixes the problem with a different apprach--it puts the close(0) call back with the code that daemonizes the application, but it's only executed if we daemonize the application. This way, users who are running mythbackend -d in a terminal are not asked whether to upgrade or not, and users who are running mythbackend in a terminal, but /not/ asking to daemonize the application, will be asked whether to upgrade.

The other possible approach was to move the daemonizing code to the location that 888a9849c put the close(0), but it seemed wrong to ask a user whether to upgrade the database when they asked to daemonize the application.

Branch: master Changeset: 68dec16c297f743c078ce966cd0c8bf404fe80a0