|Title:||Commands "read/puts" incorrectly interpret parameters.|
|Submitter:||daapp||Created on:||2011-01-05 07:09:01|
|Subsystem:||24. Channel Commands||Assigned To:||nijtmans|
|Status:||Closed||Last Modified:||2011-01-17 19:39:10|
|Closed on:||2011-01-17 12:39:10|
Bug with parameterswith tcl 8.5.8/8.6b1 with command read, this sample works, but it's incorrect: % read stdin nonewline If second parameter of read in "nonewline", than read works, but this is bug, second parameter must be number of characters to read. if replace nonewline with other word, then % read stdin xzy bad argument "xzy": should be "nonewline" Command "puts" interprep parameters the same way: % puts stdout hello nonewline hello% % puts stdout hello xyz bad argument "xyz": should be "nonewline"
nijtmans added on 2011-01-17 19:39:10:
allow_comments - 1 backported to 8.5. Closing, because at least the output-message now correctly indicates what the command syntax should be. Legacy form still works, but this is no longer visible in any error-message.
nijtmans added on 2011-01-17 18:31:06:
Checked in in HEAD with some more improvements: - Don't output a WrongNumArgs when actually the number of arguments is correct. - if TCL_MAJOR_VERSION < 9, so we will not forget to remove this for Tcl9 ;-) - First check for integer, then for "nonewline", so there is no performance peanalty any more. I see no reason to remove this before Tcl9
nijtmans added on 2011-01-06 17:46:55:
File Added - 397809: 3151675.patch
nijtmans added on 2011-01-06 17:45:35:
At least, what I would propose is change the horrible error-message to the nornal Tcl_WrongNumArgs. Then the legacy form is not exposed any more in the error message. Proposed patch attached.
dkf added on 2011-01-05 16:18:05:
It's ugly legacy code to support very old scripts. Use the forms described on the manual page (read ?-nonewline? channelId / read channelId numChars / puts ?-nonewline? ?channelId? string) and ignore these nasty things that really should have been deleted long ago. Don't know that we can actually squelch this yet. :-(