[mythtv-commits] Ticket #10090: isatty() not working via ssh, or on OS X?

[MythTV]

#10090: isatty() not working via ssh, or on OS X?
---------------------------------------------+----------------------------
 Reporter:  nigel                            |          Owner:  nigel
     Type:  Bug Report - General             |         Status:  closed
 Priority:  minor                            |      Milestone:  0.25
Component:  MythTV - General                 |        Version:  Trunk Head
 Severity:  medium                           |     Resolution:  fixed
 Keywords:  console interactive mythbackend  |  Ticket locked:  0
---------------------------------------------+----------------------------
Changes (by Github):

 * status:  assigned => closed
 * resolution:   => fixed
 * milestone:  unknown => 0.25


Comment:

 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

-- 
Ticket URL: <http://code.mythtv.org/trac/ticket/10090#comment:3>
MythTV <http://code.mythtv.org/trac>
MythTV Media Center