On Tue, May 12, 2009 at 02:07:41PM +0000, Rui Guo wrote: > On Mon, 2009-05-11 at 23:56 -0700, Robin Lee Powell wrote: > > I'd love to be able to use it basically as a replacement for > > Expect. Being able to actually *see* what was going one whilst > > driving a full-screen application with a script would be > > *really* nice. > > > > A great idea. We can definitely achieve similar functionality with > little difficulty. The problem is how to make it easy to use, > since this will not be the only use pattern. I'm not an expert of > Expect, but I think the core of it are the 'expect' and 'send' > commands.
Yep. > The second can be done even without scripting support, and thus > should not be a problem. The second is in fact an pattern matching > event, which is already in the schedule. However, the expect > command is kind of a special one-off version, which seems more > handy in such a context. I'd be fine with most any form of pattern matching and decision making based on it. Something like "wait until the window is quiscent for X time, and look for this pattern; if it exists do thus" would be fine. > However, there will be still some different with the original > Expect. By default, you can not tell which application is > currently active in screen. This means that there may be no > process handling support built in. I don't think I follow that. > One will need to use the mechanism provided by the embedded > scripting language (does LUA provide this functionality?) after > spawning a new application in a new window. Also, I currently have > no clear idea of how to support debugging. Can I assume it's less > important? I debug with "print". :) -Robin _______________________________________________ screen-users mailing list screen-users@gnu.org http://lists.gnu.org/mailman/listinfo/screen-users
