the page is to discuss ways in which pure-Tcl can be used to do some of the simpler things one might otherwise want to use Expect for.  My testing lends me to believe there is actually very little in this category, but this contradicts what is written elsewhere.

For example, in [CVS] it is stated that:

----

...ways to use cvs...

      [open "|cvs -d $cvsroot init" RDWR] and talking to
      cvs along pipes.

Will this really work? If cvs asks for my password, can I really check for that and send it back down the pipe? 

Well, yes, you can. If however there is going to be very much interaction, or if the strings being examined are going to be very complex, I (LV) would recommend looking at [Expect] as a Tcl extension to make the interaction a bit easier. 

----

Now I can get this to work with something like 'aspell' which is a standalone process, but I find that 'cvs' fires up another process (rsh) which wants the password, but Tcl doesn't know anything about that...

I understand that for complex uses Expect is obviously the way to go, but if all I want to do is make sure 'cvs' gets my password, it sounds like it would be easy enough just to use pure Tcl.  Here's a code outline:

    cd c:/tcl-source/tcl
    console show
    update

    proc go {} {
	set pipe [open "|cvs -z5 update ChangeLog" RDWR]
	fconfigure $pipe -buffering line -blocking 0
	fileevent $pipe readable [list piperead $pipe]
	return $pipe
    }

    proc piperead {pipe args} { 
	if {![eof $pipe]} {
	    puts "read $pipe : $args" 
	    set got [gets $pipe]
	    puts "got: $got"
            if {[string first "password" $got] != -1} {
                puts $pipe "my password"
            }
	}
	update idletasks
    }

    go

Something like the above can be made to work to interact with 'aspell' to perform spellchecking, but when using cvs, it fires up a separate 'rsh' process which is looking for input, but Tcl doesn't know that, so the above doesn't work.

Any ideas to solve that problem?

----

[Category Expect]