screen-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[screen-devel] [Fwd: Some thoughts about screen scripting support.]


From: Rui Guo
Subject: [screen-devel] [Fwd: Some thoughts about screen scripting support.]
Date: Sat, 28 Mar 2009 12:29:55 +0800

Hi all,

I got some thoughts about screen scripting support and would like to
share with you.

Rui
-------- Forwarded Message --------
> From: Rui Guo <address@hidden>
> To: address@hidden
> Subject: Some thoughts about screen scripting support.
> Date: Fri, 27 Mar 2009 12:03:27 +0800
> 
> Hi Sadrul,
> 
> I've thought a bit more about the idea of screen scripting support.
> 
> The current use cases demonstrated fall into two catalogs:Event
> triggered handlers and user triggered actions. In both cases, we need to
> provide a interface to let them query the status of screen and execute
> actions on screen. The only difference would be the latter need a
> triggering interface for the user to use. In summary, we need to define
> a more complete set of events and possibly the interface too. There are
> four kinds of object to manipulate with, in addition to the root object
> screen, however they only provide limited functionalities.
> 
> In addition to the above, I would like to show another kinds of use
> case. Not sure whether you will like it. 
> 
> Screen some times is called as a window manager. However, for historic
> reasons, the program running within screen does not interfere with
> screen. They even not aware of the existence of screen. If they would,
> some possibilities will show up. Imagining having a separate output
> buffer for shell commands executed in vim, that may be possible if we
> provide an robust interface for them. However, it's not likely for the
> program itself to interface with screen, since they will have to run
> outside screen. And this is where I think scripting can be taken into
> account. It can act as a middleman for the two.
> 
> However, this scheme complicates things a little. Here, the script, on
> behalf of the client application, is no longer a slave to screen. They
> may need to run in background and communicate with screen when
> necessary. This requires the script and the screen can run
> asynchronously. 
> 
> What do you think about this idea? Currently, the command switch -X can
> be used to send command to a running screen session. The use case I
> showed here is only a more powerful scheme of this.
> 
> Looking forward to your reply.
> 
> ps: Should I send a copy of this to screen-dev?
> 
> Regards,
> Rui 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]