ID:77559
 
BYOND Version:451 and below
Operating System:ALL Non-Windows
Web Browser:
Status: Unverified

Thus far we've been unable to verify or reproduce this bug. Or, it has been observed but it cannot be triggered with a reliable test case. You can help us out by editing your report or adding a comment with more information.
Descriptive Problem Summary:
BYOND's data handling automatically assumes a Windows-Based Enviroment. This can cause issues such as outputting information into a text file, which on non-windows systems (Linux I.E) will lead to undesired mess in data files.

Numbered Steps to Reproduce Problem:

Code Snippet (if applicable) to Reproduce Problem:
world/New()
world.log = file("Output.txt")
world.log<<"This is a line of text."
world.log<<"This should be a seperate line of text"
shutdown()


Expected Results:
Output.txt Contents:
--------
This is a line of text.
This should be a seperate line of text

Actual Results:
This is a line of text.[]This should be a seperate line of text
(Note: the [] is the Special Character for RETURN CARRIAGE which Linux does not understand)

Does the problem occur:
Every time? Or how often? Every time on Linux
In other games? ALL things handling data files
In other user accounts? ALL accounts
On other computers? Linux-Based Computers

When does the problem NOT occur?
On Windows based systems

Workarounds:
None

Proposed solutions:
1) Offer a variable where we can supply the information for a return carriage (Seeing as we already have variable with the servers enviroment)
-or- 2) Make BYOND take awareness of different character returns on different operating systems and use the systems native ReturnCarrage.
Have you tried using the text2file() proc in stead of bluntly using somefile<<"sometext"
Nielz wrote:
Have you tried using the text2file() proc in stead of bluntly using somefile<<"sometext"

You're going to text2file() something into the world.log?
Falacy wrote:
Nielz wrote:
Have you tried using the text2file() proc in stead of bluntly using somefile<<"sometext"

You're going to text2file() something into the world.log?

You can as well write to the file directly in stead of through world.log
Even using text2file() causes the same issues.
Everything I'm looking at in the code says that the \r character should not be added at our end. It's possible the UNIX C libraries are doing this, but I have a hunch that's not the case. At any rate I see no evidence of an extra carriage return character being added.

Your bug description contains one particular oddity though. If the text file has an extra carriage return along with the newline character, you might be seeing the extra char but you should also be seeing a line break. The text as you've presented it though is exactly how the text would look in Notepad or a text box, if you copied the contents of the file to a Windows machine without it converting formats first. Notepad doesn't understand the line break character all by itself, so it prints a box or something like it, and it does not print the line break.

For clarity, are you viewing the file directly in Linux with "cat Output.txt", or are you downloading the file to a Windows machine and trying to open it there? If it's the latter, then I suspect your file transfer program is not converting the text file into a proper PC format which does require the carriage return, and that would completely explain what you're seeing. You might also see this if you were trying to view the contents of a file directly in your transfer program, since some of them allow that.
It's not a matter of what I should see on windows that is the issue. It's what I see on linux that is the issue.
But that doesn't entirely answer my question. Are you using the cat command to view the file contents, or some other method? And are you seeing the carriage return in place of the line break, or in addition to it?
In addition
Yes using cat command.
I have attempted to reproduce this issue using your code on a UNIX machine, but viewing the output file with cat shows the correct results. I also confirmed the binary format of the file does not include any carriage returns. There may be something more specific to your OS that's behind this.

For completeness' sake, please edit your report to include the exact BYOND version ("ALL" is not appropriate for a report because we need to know which version specifically the issue was seen with) and the OS. That info may be important to the bug and will be more helpful when revisiting the issue.