yvan dot rivard
This might seem silly for experienced users, but this bugged me for about two hours (searching and trying to debug the damn thing).
If you're on a Windows system doing tests on a Linux/Apache setup, and you're writing stuff to a text file (then load that file to see if your content is being written properly) and you realize only your first string is in there, your problem is not your Windows, not Linux and not Apache. It's probably Samba (the thing that makes it possible for your Linux and Windows boxes to talk to each other) that's caching your file... Try viewing your file via telnet or simply copy your file then read that copy.
You can see content is being written to your file anyway, because even though you don't see your new content (using notepad for example), you do see your filesize increasing as you add more text to your file.
The way I understand fputs (which is purported as an alias to fwrite which can be "Binary Safe")...
$fp = fopen("something.txt","w");
$string = "Hello World\\n"; // escape the slash from being magically
// being transformed into a newline
fwrite($fp, $string); // will proccess /n as newline ...
fwrite($fp, $string, strlen($string)); // will write the entire string to file without changing the '/n'
// into a single byte for newline on Unix-like machines or CR/LF on Win32 machines
Hope this helps explain the definition of "could be Binary Safe". This is the reason why you must specify the length!
Length is required if you are writing out a lot of data. For instance, if you are base64 decoding an email attachment and writing it out to a file you have to specify the length if the file is over a certian size or else the binary data will be corrupt.
Will yield the desired results.
When tested with a 1k the length wasn't required but with a larger file, around 27k it needs the length to work properly.
as a continue of rembert:
so you should always use strlen($cmd) as third parameter if you use fsockopen -- because nearly everything you write e.g. in telnet or ssh has 2 or more "words".
(proud user of php4)
Adding to Adam (Nedstat):
fputs without the length parm just writes all data up to but not including the first 0 byte it encounters.
Therefore fputs($fp,"hello\0world") will only write hello to $fp whereas
fputs($fp,"hello\0world",11) will write both words.
If this doesn't make sense for you, remember strings are always terminated with that 0 byte. Binary data doesn't have such a terminator byte as a 0 byte can be a completely valid piece of data therefore you always need to know the length of the binary datapart.
BTW strlen() is binary safe, so you can use that to get the length of the binary data part as well - this is different from C which counts the number of chars up to the 0 byte. So the example above could also be written as:
A note about including length: if you are writing binary data you should *always* specify the data's length. The reason is that the operating system has a special character to denote end of *strings*, but not for binary data. Binary data can be anything, so you can't very well reserve an end-of-data character. So the reason why writing binary data without specifying it's length can truncate it is that the only thing the system has to go on (without writing the entire contents of memory starting at the variable's address) is the end-of-string character, which could very well appear randomly in the middle of your set of binary data. The reason that length() could have worked on the variable is that it is implemented in C as sizeof(), which actually fetches the size of the memory chunk associated with the variable, but this is not advisable because sizeof() can also return the size of the *pointer* to the variable if you're not careful (ie, passing it by reference into a second function). In C it's best to keep track of size of the data you are accumulating as you accumlate it, so probably in PHP, too.