> I'm skeptical of the notion that cmd.exe is diddling with your data en > route to the pipe. I can't think of a time Windows munged my data in > that particular way despite more years using that lousy tool than I > care to remember. Quotes and escapes, sure, don't get me started.
I would echo this: it's good at mangling the command-line, but I've not been aware of it ever mangling data sent to a file/stream (other than the binary/text mode conversions). > Shot in the dark: maybe a string is being continued by ending the > line with a backslash. If the output handle is opened as text with > fopen, the sequence would be > 5c 0d 0a > which the escape-reader wouldn't recognize, expecting only > 5c 0a > leading to a noncontinued, incomplete line. I don't believe this would be the case, if both stdin and stdout have been left in "text" mode: '5c 0a' sent to stdout would be converted into '5c 0d 0a' but when this was read in "text" mode it would get converted back to '5c 0a' which would be what the "escape-reader" of SQLite would see. > But that doesn't explain the difference between redirecting to a file > and redirecting to a pipe. Even if the data coming from the first command contained characters that "confused" the "text" mode of Windows, I would expect things to work or fail the same whether the output's being piped or sent to a file. My "shot in the dark" would be that some buffer-size limit in the piping process is being exceeded. Graham Holden _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
