Any commands that are executed through the public interface using SBCommandInterpreter::HandleCommand() are assumed to be in non-interactive mode.

Any commands that want interactivity (stdin) will need to be executed through the normal command interpreter using the debugger's in/out/err file handles, or by using "command source".

Individual commands through the API will have their STDIN disabled. The STDOUT and STDERR will be redirected into the SBCommandReturnObject argument to SBCommandInterpreter::HandleCommand() as usual.

This helps with a deadlock situation in an IDE (Xcode) where the IDE was managing the breakpoint actions by setting a breakpoint callback and doing things manually.

<rdar://problem/17386271>

llvm-svn: 213023

lldb/source/Interpreter/ScriptInterpreterPython.cpp

@@ -2438,7 +2438,7 @@ ScriptInterpreterPython::RunScriptBasedCommand(const char* impl_function,
     {
         error.SetErrorString("invalid Debugger pointer");
         return false;
-    }
+   }
     
     bool ret_val = false;
     
@@ -2446,7 +2446,7 @@ ScriptInterpreterPython::RunScriptBasedCommand(const char* impl_function,
     
     {
         Locker py_lock(this,
-                       Locker::AcquireLock | Locker::InitSession,
+                       Locker::AcquireLock | Locker::InitSession | cmd_retobj.GetInteractive() ? 0 : Locker::NoSTDIN,
                        Locker::FreeLock    | Locker::TearDownSession);
         
         SynchronicityHandler synch_handler(debugger_sp,