QTerminal does not work on OS X

[GoogleCodeExporter]

1. Running QSciTE from a terminal, as soon as the bash shell starts, the
QSciTE job becomes "stopped" and refuses any attempt to restart it.
2. Running by double-clicking the QSciTE bundle, the terminal simply
becomes a dumb text field. Meanwhile, the bash process runs away and drives
CPU usage to 100%.

bash may be setting its standard I/O to values inherited from the parent
process, instead of allowing the parent process to set them.

Original issue reported on code.google.com by bfrobin...@gmail.com on 17 Feb 2008 at 8:33

[GoogleCodeExporter]

Interesting.  I'm having problems on Windows too: as soon as QTerminal starts
cmd.exe, it prints out the prompt and then exits (but QSciTE is otherwise OK).  
This
may take quite a while to get working on all three platforms... :)

Luckily I've got the toggling written, so it shouldn't mess anything else up 
for the
time being.

It'd be interesting to stick a debugger on it in OS X...

Original comment by jpsut...@gmail.com on 17 Feb 2008 at 8:51

[GoogleCodeExporter]

BTW Ben, my dual G4 died a while back, so you'll need to take the lead on 
making sure
this is (and stays) working on OS X. :)

Original comment by jpsut...@gmail.com on 17 Feb 2008 at 8:54

[GoogleCodeExporter]

Potentially fixed in r50.
The new implementation of QTerminal ( qterminal_pty.{cpp, h} ) works in OS X.
I used raw POSIX syscalls, so I know we will need something different on Win32.
Check whether the OS X implementation works on Linux.

Original comment by bfrobin...@gmail.com on 18 Feb 2008 at 3:51

• Changed state: Started

[GoogleCodeExporter]

Doesn't compile on Linux.  It complains about "#include <util.h>"  So, I 
searched
around, and forkpty() is in pty.h while FD_COPY is supposed to be in fd.h 
(according
to several online man pages), however, I can't seem to find it.  I just grepped 
my
/usr/include folder and I can't find any header file with that function.  
Anything
else we can use?

I'm committing a partial fix (only include "<util.h>" if __APPLE__ is defined,
otherwise include pty.h and fd.h (subsitute another header file if one is found 
with
the right definition).

Original comment by jpsut...@gmail.com on 18 Feb 2008 at 4:10

[GoogleCodeExporter]

After hacking around, it compiles and links, but prints "select() timeout"
continuously to stdout (and CPU spikes, but because of the CPU core balancing it
doesn't kill my system :) )...

Original comment by jpsut...@gmail.com on 18 Feb 2008 at 4:46

[GoogleCodeExporter]

Revision 56 is much improved.  Any applications that interact much more than 
printing
to stdout are rather useless (top, vi, etc.), but I imagine that if someone 
wants to
use one of those utils, he'll probably already have a separate application 
open. 
Also, things like "clear" don't work (I assume they pass an escape sequence 
that the
shell is supposed to pick up and act on).

Let's not worry about windows for the time being.  The lack of POSIX compliance 
makes
me shudder.  We'll probably need to do a separate terminal class for it, and 
we'll
dynamically enable it if windows is detected at compile time.

Original comment by jpsut...@gmail.com on 18 Feb 2008 at 10:44

[GoogleCodeExporter]

QTerminal is working well enough that I'm closing this bug.
Remaining wishes can be filed under their own issues.

Original comment by bfrobin...@gmail.com on 19 Feb 2008 at 11:52

• Changed state: Fixed