>> (a) Does anyone have any other ideas, not mentioned above, for how >> to address these issues? > Not really, I would suggest using a pty even though you have > dismissed it.
Well, FSVO "dismissed". It seems ridiculously heavyweight for the task; it also feels wrong. Here, we have software that's crippled by lacking support for producing its output in a generalized fashion - so, rather than fixing the limitation, we depend on a heavyweight OS feature to work around it? That's like, oh, say, we have a language that lacks support for decimal numbers, so, instead of fixing that, we add a front end which converts all numbers to octal or hex. Most briefly, I would prefer to fix the problem instead of just tacking on a workaround. For testing libcurses, the pty method is probably necessary, since you want to test the tty interface code as well. But for testing just the screen updater (which I suspect is where most of the hair lies), why should you have to go through the kernel at all? Make it a well-isolated unit and you can then unit-test it. > The libcurses atf test does this to test curses functions, capturing > the output and comparing it to an expected output. It uses poll(2) > to check for i/o so as to prevent blocking on reads and writes. But it needs an additional process, or at least thread, or it's vulnerable to blocking when dealing with a large update. Even heavierweight. >> (b) Does anyone know of any work done towards pulling the screen >> updater out of curses, so it can be used without all the baggage >> tied to the OS that libcurses imposes? > No. I am not really sure what general use it would be. Sure, you > have a very specific need, that I can understand but struggle with a > generalised concept. I have two use cases already, and I have two more which are vulnerable to the same issue but which I haven't actually run into it with...yet. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
