go to bug id or search bugs for
recode_file() generates a spurious warning when the 'input' file handle has had data sent to it from a file handle that references a remote system. Despite the warning, the recode attempt succeeds - converting between character sets and writing the data to the 'output' file handle
See the script below.
# Open a local file (instead of URL) and no warning is generated
$input = fopen ('http://www.netscape.com/', 'r');
$tmp = tmpfile ();
while (! feof ($input))
fwrite ($tmp, fgets ($input, 1024));
recode_file ('us..flat', $tmp, tmpfile ());
Add a Patch
Add a Pull Request
I think that problem comes from the fwrite source code
( however my C skills are minimal and I have not carefully dug through the code :)
It seems that when fwrite gets data from a file handle with issock set, it in turn has issock set - thus making recode unhappy...
(This is my blind guess. Hopefully this helps point out the problem (or at least amuses someone :). If I get a chance, I will try to analyze the problem in more detail - however, I short on skill and time for this kind of work.)
This is not a file problem, this is an us..flat recoding
problem. recode says on that:
recode: Ambiguous output in step `ISO-8859-1..ASCII-BS'.
I guess us..flat recode doesn't like CRs that are many in
Netscape's HTML. This is actually a bug - one shouldn't use
both LF and CR-LF line endings in one text. But it's not a
recode bug, I guess.