(no commit message)
authorjwalzer <jwalzer@web>
Sun, 14 Feb 2010 14:50:51 +0000 (14:50 +0000)
committerJoey Hess <joey@finch.kitenet.net>
Sun, 14 Feb 2010 14:50:51 +0000 (14:50 +0000)
doc/forum/Warnings:___39__utf8___34____92__xAB__34___does_not_map_to_Unicode_at___47__usr__47__share__47__perl5__47__IkiWiki.pm_line_774__44_____60____36__in__62___chunk_1.__39__.mdwn

index 931e339e25bf63a38d48c12f77cdea8c042673f4..72f2d38e0be0b4d1590aedb9fd65e25ee9b48edd 100644 (file)
@@ -34,3 +34,14 @@ I'd rather cleanup some of the file(name)s  of unexpected characters. --[[jwalze
 
 
 But what I see now is not quite helpful, as it seems, STDERR and DEBUG are asyncronous, so they mix up in a way, that I can't really see, whats the problem ...  Maybe I'm better off for troubleshooting, to insert an printf to strerr to have it in the same stream.. --[[jwalzer]]
+
+
+----
+
+**Update:** The "print STDERR $file;"-Trick did it .. I was able to find a mdwn-file, that (was generated by a script of me) had \0xAB in it.
+
+Nevertheless I still wonder if this should be a problem. This character happend to be in an *\[\[meta title='$CHAR'\]\]-tag* and an *\[$CHAR\]http://foo)-Link*
+
+Should this throw an warning? Maybe this warning could be catched an reported inclusively the containing filename? maybe even with an override, if one knows that it is correct that way? --[[jwalzer]]
+
+[[!tag solved]]