You stated "while not explicitely stating it's a bug, Khaled, by not saying it's not a bug, agreed with this."

The only thing you can assume out of his message was that this has been the implementation since 5.5 settled upon by himself and several beta testers, He did not say one way or the other it was a bug or not. The only thing you could assume is that he's weighing the odds, and coming to his own conclusion, which also includes the result of affecting any scripts that may be accustomed to it's default behavior way back since 5.5


read this article.

https://en.wikipedia.org/wiki/Newline

You using -n improperly for anything besides text does not constitute this as a bug. I'm sure you can find either character within a binary file, these don't mean "newline" in this case.

You wouldn't sockread in to a %var, bset -t it and brwite it to a file and expect it to be correct as-it-came from the socket, same sense, you wouldn't sockread into a &binvar, and /write $bvar(&var,1-).text to a file and expect it to be correct as-it-came from the socket either.

Similar to FTP protocol, if You're using ASCII mode for transfer, it's under the assumption of text, and has no issues with files that are of text. Upload an image file or something that may contain chr 13 or chr 10 which does NOT mean new line, and the file is corrupted. Use BIN mode and the file transfers perfectly fine perfectly in-tact.

I don't know what you're doing but obviously you're not dealing with text, or trying to mix the two, either way you seem to be attempting to treat it as-if it were text.

If you are attempting to mix and match, and this is your own design, try looking at other protocols that already does this behavior such as HTTP. The header starts out as text, to break "text-mode" two newlines are sent. Depending on the content type you recieved, the result of the data that follows afterwards may need handled in a different manner or continue on as text such as a content-type of text/plain, a good example for mix-and-match using both together is a content-type of multipart/form-data.

Under multipart/form-data, a special sequence is given to mark where the transmitted content would end commonly known as the boundary. you are again given sub-header details relaying what is in this particular section, which again marks the end of the sub-header with two newlines. Anything after that should be treated as binary data, and be processed as such until the found "boundary" sequence, marking the end of that section, and potentially the start of a new one.

Multipart header example
Code:
POST /path HTTP/1.0
Host: example.com
Content-type: multipart/form-data, boundary=AaB03x
Content-Length: xxxx

--AaB03x
content-disposition: form-data; name="field1"

<whatever was field1's data>
--AaB03x
content-disposition: form-data; name="field2"

<whatever was field2's data>
--AaB03x
content-disposition: form-data; name="file"; filename="files name"
Content-Type: some mime type
Content-Transfer-Encoding: binary

<RAW file data from a input type of file (selector)>
--AaB03x--