Closed GoogleCodeExporter closed 8 years ago
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
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
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
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
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
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
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
Original issue reported on code.google.com by
bfrobin...@gmail.com
on 17 Feb 2008 at 8:33