Re: [screen-devel] Shared screen for help with simultaneous debugging

[Fernando Vezzosi]

Hi,

You should not hit the «reply» button, when starting a new thread.

On Sun, Jun 15, 2008 at 10:29:27PM +0530, Kumar Rangarajan wrote:
> My company works on doing a lot of migration related work, and we do a
> lot of unix to unix migrations.

While my attached code will not help you on exotic Unices, it definitely
works on Linux, and I believe it does on BSD.  It uses the TIOCSTI
sysctl on the term devices.  It may trash the terminal from where you
run it.  Just `reset`. :)

> Here is where I wanted to see if I could improve things. What if the two 
> screen windows ran on a 'shared keyboard' session. Ie irrespective of 
> which window I am, the key strokes typed on that window should be made 
> visible to all its 'shared' sessions. So basically if I type 'next' on 
> one debugger session, the same command should be made available to the 
> other window too.

> Is there such an option already available under screen ?

Not that I know of, but the command «stuff» lets you insert
characters/strings into another window's input buffer.  I would use
that.  You might want to look into its implementation.  Looping over a
series of windows, and calling "stuff" for each of them, sounds like
doable.

Alternatively, see the attached code.  You may need to run it as root.

  (on pts/5)$ ./cscreen -t /dev/pts/3 -t /dev/pts/4

Whatever you type into cscreen pts/5 (yes also control characters), gets
sent to pts/3 and pts/4.  Of course if you switch to pts/3 and type
something, only pts/3 sees it.  I've been using this across clusters,
and whatnot.

It exits on ^C, so I've never used it for gdb.  You may need to tweak
signal handling and/or curses interaction.

> If not, I would certainly be interested to work on this. But I am a  
> complete novice on screen development and its source base. Any pointers 
> on where I should start to understand screen and its source base and also 
> pointers for this particular enhancement would be really great.

comm.c and process.c are the best candidates, IMHO.

Cheers,

-- 
  Fernando Vezzosi
               3F29 4D20 510E E1AE 991D  3B12 D6BE 7C05 B289 97C9

Makefile
Description: Text document

cscreen.c
Description: Text Data

signature.asc
Description: Digital signature