On Mon, 9 Jan 1995 10:11:45 +0000 (GMT),
Ross Wakelin <rossw@march.co.uk> said:
Ross> Configure
Ross> the configure scripts do not yet get the libnsl and libsocket
Ross> stuff right, and have to be hand amended. Sorry.
It should and I think it does on solaris. If not, can please someone
look into the configrue script (perhaps running it through sh -x) and
send me a patch to fix this? I have no SYSV boxes around here :-)
Ross> scotty tcp command
Ross> there is a "problem" related to the tcp command in
Ross> scotty. In the SVR4 environment, "files" are streams
Ross> based, including socket connections. The tcp command
Ross> opens a socket, which is then fdopen'ed into a FILE
Ross> type, which is then handled normally using the
Ross> standard tcl gets, puts etc commands. Unfortunately,
Ross> in the streams environment, you cannot (CANNOT) puts
Ross> onto a stream file after a gets (or any combination of
Ross> write after read) UNLESS you do an intervening seek
Ross> (fseek, fsetpos etc.). This is not just scotty, but
Ross> applies to any tcl on a FILE stream. If you do not do
Ross> the seek, you get an error 9, EBADF, bad file, when
Ross> you try to do the puts. Using scotty/tkined, this
Ross> error appeared whenever you used the tcp connect
Ross> feature, especially in the netguard code. This can be
Ross> fixed by prefixing any puts command with: seek $socket
Ross> 0 current
This one is interesting. I am not sure if the streams emulation is
wrong here or if it is just a problem with the FILE implementation of
various C libraries. Scotty uses setbuf() to set the FILE buffer to
zero and hence every access to the FILE handle should result in a
read() or write() on the underlying socket. Can you check, if an
intervening flush on the tcp file handles works just like the seek
you were using?
My experiments showed that mixed gets/puts work fine on ULTRIX-4.4,
HP-UX-A.09.03, SunOS-4.1.3 and Linux-1.1.78. An AIX-2 box did not run
my test, but it did when I called flush between gets and puts. Here is
my test script:
proc getsputs {{flush ""}} {
set f [tcp listen]
set p [lindex [tcp info $f] 1]
set A [tcp connect localhost $p]
set B [tcp accept $f]
puts $A does; gets $B r1; eval $flush
puts $B it; gets $A r2; eval $flush
puts $A work; gets $B r3; eval $flush
puts $B ?; gets $A r4
tcp close $B
tcp close $A
tcp close $f
return "$r1 $r2 $r3 $r4"
}
if {[getsputs ""] == "does it work ?"} {
exit
}
if {[getsputs "flush \$A; flush \$B"] == "does it work ?"} {
puts "([exec uname -a]) needs flush"
exit
}
if {[getsputs "seek \$A 0 current; seek \$B 0 current"] == "does it work ?"} {
puts "([exec uname -a]) needs seek"
exit
}
Could you please run this script and send me an email if it produces
any output? Perhaps we can fix this somewhere in tcl if it is a common
problem. Or are there some other ideas how to fix it in scotty?
Ross> netguard
Ross> fixed the above tcp seek problem. the variable
Ross> ETC_DIR does not get modified by the install/Makefile
Ross> system, despite the comment to the contrary in the
Ross> source. In several places in the code, (usually
Ross> handling lists of results) the construct: foreach item
Ross> in list of items set item to lindex 0 of item then do
Ross> work on item appears. The "set" command seems to be
Ross> unneeded, and in fact breaks the code
The netguard code is not maintained by us as we do not use it
anymore. I know that people have spend some time to get it to work
again, but I never received any patches for it. If you send me
patches, I would put them in so your work might be useful to others. I
could also take the netguard code out of the scotty sources if there
is someone who wants to maintain it...
Juergen