strange variable printing problem

[sparc317]

Ok... managed to solve my sockets problem Used the awesome ::sock:: stuff that was posted here instead.

I can't for the life of me work out why this isn't working though:

Code: Select all

# Handle output from the server and print chat messages to channel
proc read_sock {sock} {
  set gsoutput [gets $sock]
   if {[string match *Chat* $gsoutput]} {
    puthelp "PRIVMSG #admins :Pub 2 - $gsoutput"
   }
}

That works fine, it matches the string within $gsoutput and prints the message.

HOWEVER it doesn't print the contents of $gsoutput. For example if $gsoutput contains "Chat: foobar"

It just prints in the channel "Pub 2 -" instead of "Pub 2 - Chat: foobar"

Any ideas on this?

Thanks![/code]

[rosc2112]

Are there carriage returns in the $gsoutput? That'll make puthelp not print the stuff after any carriage returns. You can use putcmdlog to check the contents of the var:

putcmdlog "gsoutput '$gsoutput'"

or:

foreach line [split $gsoutput \n] {
putcmdlog "line '$line'"
}

If there's carriage returns, clean up $gsoutput with regsub:

regsub -all {\n} $gsoutput {} gsoutput

Also, you might need to ensure $gsoutput doesn't have tcl special chars:

set gsoutput [split $gsoutput]

would protect/escape any tcl special chars that might be present in the output, then you can use:

puthelp "PRIVMSG #admins :Pub 2 - [join $gsoutput]"

[sparc317]

Cheers for the reply, really apprecitated.

The output of putcmdlog when printing the contents just gives:

Code: Select all

[21:09] gsoutput '

So its missing even the last ' off the end.

I've tried the removal of TCL special chars and newline as suggested but still no joy.

What is even more bizarre, is if I fire up a netcat listen server and paste the EXACT same string in and send it, it prints it fine!!!!! Its only when connecting to the server itself.

I know the data is there as I have TCP dumped it and it also wouldn't match otherwise.

So strange

[nml375]

The first thing that comes to mind is non-blocking sockets:
Calling gets on a socket set up in non-blocking mode results in two possible outcomes:

• Socket has a complete, unread line with trailing newline:
  Line will be read, the filepointer advanced, and the read text will be returned
• Socket has unread data, but no trailing newline:
  This line can't be read, as it's ont yet completed. Since we're not blocking, gets simply returns an empty line.

@Rosc:
Your splitting and joining really does'nt make much sense.

Code: Select all

join [split "sometext"]

This will always return exactly the text or data that was used in the first place... Split should only be used when you wish to convert strings into a tcl-list, and absolutely nothing else. Thinking of it as a magic fix is very dangerous. Also keep in mind that glob-matching done by string match (by default) has a completely different ruleset for escaping than lists.