invoking the jun17 version of tkdiff with wish9.0 on the two files uploaded here, an error happens. It doesn't happen with wish8.6. I have no idea what the multibyte character is but it seems to be in both dirdiff and tkdirdiff.
tildChk: SPLIT frags(dirdiff) INITIALIZATION
Dbg: +++ Default V9 1st Frag newf1(dirdiff) to later update canon
Dbg: *** REWROTE(result(1)) CANON(dirdiff) w/converted 1st frag(dirdiff)
tildChk: SPLIT frags(tkdirdiff) INITIALIZATION
Dbg: +++ Default V9 1st Frag newf1(tkdirdiff) to later update canon
Dbg: *** REWROTE(result(1)) CANON(tkdirdiff) w/converted 1st frag(tkdirdiff)
Error in startup script: error reading "file6": invalid or incomplete multibyte or wide character
while executing
"read $hndl"
(procedure "rediff" line 21)
invoked from within
"rediff "
(procedure "check-error" line 18)
invoked from within
"check-error $result $output"
(procedure "do-diff" line 20)
invoked from within
"do-diff"
(procedure "main" line 101)
invoked from within
"main"
(file "/home/dorothyr/Downloads/tkdiff-jun17" line 18692)
Filetype gives a clue, although I don't know how or why this happened
$ file *
cvsdiff: POSIX shell script, ASCII text executable
dirdiff: POSIX shell script, ISO-8859 text executable
tkdirdiff: POSIX shell script, ISO-8859 text executable
Here's the relevant tcl9.0 manpage
https://www.tcl-lang.org/man/tcl9.0/TclCmd/chan.html#M48
On Sun, Jun 22, 2025 at 12:52 PM DorothyR dorothyr@users.sourceforge.net
wrote:
--
From my gmail account
Related
Bugs:
#101Oh great it's the copyright string:
776:Copyright � 1999-2005 Paul Mackerras
Here's the relevant tcl9.0 document
https://www.tcl-lang.org/man/tcl9.0/TclCmd/chan.html#M48
Last edit: DorothyR 2025-06-22
Sadly, that document fails to describe how things GOT that way, only what one should do once it does. After a great deal of hunting, it was discovered that something called an encoding "profile" was what is NEW in V9.0.x and can now be seen from the 'encoding' and 'fconfigure OR chan configure' commands - yet oddly MISSING from 'open'!!
There are 3 provided "profiles":
1. tcl8
2. replace
3. strict
for which V9.x chose #3 as the DEFAULT - thus the complaints when a "mixed" encoding occurs.
The #2 choice appears to be a "recipe" for going about an on-the-fly de-coding/re-coding of the offending data, and #1 further appears as an implementation OF that #2 approach, which just happens to be what TCL V8.x.x had always done in the past!
Thus the most direct solution is to choose "-profile tcl8" and just GET the substituted "unknown" cipher as you've documented above (without any thrown errors); OR - undertake building ones own "converter" (to use the "-profile replace" option) again with no-errors; OR - follow the instruction from the mentioned man page to deal with not only the thrown error, but trying to find a suitable OTHER encoding to continue processing the data (no easy task as even the recommend iso8859-1 encoding still HAS its own "illegal" bytes considered as OUTSIDE its own BINARY representation form: Re: the example on the "encoding" man page).
Bringing this to our attention is deeply appreciated, but barring any further information, it should be evident that TkDiff will take the "-profile tcl8" approach, as there is a long history of zero complaints against the results produced to date.
Issue has been addressed via new release (Version 6.0)