This might be true. I have no idea. I compile on a System V system.
> I'm unable to build the "panel" module at all - i don't see any
> panel.h include files on my system, or a libpanel.* in the regular or
> System V compatability libraries. Is the panel feature specific to
> some other OS? Or might the routines for it be available in my OS,
> but in a library with a different name?
I was not sure if any other system supported panels... SCO does but
I have no idea if anyone else does.. sorry.. Again, I use SCO.. so I have
no idea what is on other platforms.. I have not looked at the dozens of
systems at work since I am a long way from work.
> I've encountered two problems with the way the curses package behaves.
>
> The first is fairly straightforward - the .initscr() module method
> will, as documented, exit the parent program if it is invoked on a
> terminal that is not curses capable. If i understand correctly, the
> curses solution is to use the newscr() routine, which does not do the
> _exit if it is not successful. The problem is that screens are not
> yet implemented in the curses module, and i can't see a way to test
> for curses-capability without risking the initscr() method. ?
I will be adding SCREENs to the curses module. But I have to do other things
first. I don't like the behavior of the initscr() 'C' level call either.
When I get a chance to do that, I will post the diffs.
> Finally, i see a weird and troublesome behavior of nodelay-reads
> within curses. If i invoke the win.nodelay(1) method and then a
> win.getch(), python exits *and* the tty session exits! It looks like
> the tty gets set overall to nodelay, and immediately sees an EOF
> condition (if there is no prior input pending), all the way up the
> line. Does anyone else see this behavior, and does anyone have
> suggestions for preventing it??
This does not happen on my system at all. It works correctly. I have
to assume it is because SysV and BSD set up the line handlers differently.
-- Lance Ellinghouse lance@fox.com