IO#putc writing 2 bytes?

[Minic Minic]

Hey all, thanks for reading. Today is my first attempt at getting some
hands on with Ruby. So far so good, but I'm having a slight issue I hope
to clear up.

Anyways, I decided to write a SRAM save file editor for a popular
GameBoy game. Problem is for some reason putc is writing 2 bytes when
ever I try to write 0x0A. It instead writes 0D 0A into the file.

Heres my code (go easy, first attempt at Ruby ever xD )

def ZeldaEdit.ChangeBButtonItem()
ZeldaEdit.ListItemValues()
ZeldaEdit.ReadBButtonItem()
printf("Enter new item value from the list above: ")
@NewItemB = STDIN.gets.chomp #1
@NewItemB = @NewItemB.hex
@SaveFile.pos = "0x405".hex
@SaveFile.putc @NewItemB #2
end

If I type "a" at the gets for #1, once it gets to #2 is putc's 0D 0A.
If I enter 0-9 or B-F it works just fine, the problem seems to only be
with A. For the past few hours I've been scratching my head. I have no
clue why it is doing that, when other values work just fine.

Any help is greatly appreciated, it's not a crucial project by any
means. Just a learning experience.

Thanks in advance for your help!
-Minic

 

[Jos Backus]

Anyways, I decided to write a SRAM save file editor for a popular
GameBoy game. Problem is for some reason putc is writing 2 bytes when
ever I try to write 0x0A. It instead writes 0D 0A into the file.

Looks like you are on Windows. Try opening @SaveFile in binary mode (@SaveFile
= File.open("fname", "wb")) which prevents LF -> CRLF conversion.

 

[Minic Hoberoff]

Ah ha! Indeed I am on Windows. I knew about the LF to CRLF conversion,
but it never struck me.

To make a long story short, I tried to open the file with mode a+b which
was what I needed. Then @SaveFile.pos quit working on me even after
@SaveFile.rewind, it would write to the end of the file. So I
@SaveFile.binmode and BOOM, my first Ruby script is now working as
intended!

Thank you so very much. I never would of figured it would do the
conversion when not in binary mode.

So now the REAL question is, am I to blame or is Windows? (don't
answer that)

Thanks again, you truly made my night!
-Minic

 

[7stud --]

Looks like you are on Windows. Try opening @SaveFile in binary mode
(@SaveFile
= File.open("fname", "wb")) which prevents LF -> CRLF conversion.

Why would that help? The output in the file is 0A 0D, which is a
windows newline. If the file was not opened in binary mode, that means
the ruby code must have tried to write '\n' to the file, which ruby then
converted to the OS's newline, which for windows is 0A 0D. However,
getting the string "a + newline" from the user and then chomp()'ing off
the newline should leave you with "a". And using putc() to write the
string "a" to a file does not involve any newlines.

 

[Eleanor McHugh]

Why would that help? The output in the file is 0A 0D, which is a
windows newline. If the file was not opened in binary mode, that
means
the ruby code must have tried to write '\n' to the file, which ruby
then
converted to the OS's newline, which for windows is 0A 0D. However,
getting the string "a + newline" from the user and then chomp()'ing
off
the newline should leave you with "a". And using putc() to write the
string "a" to a file does not involve any newlines.

Because he's not reading or writing 'a' (ASCII character 97) but the
linefeed character (ASCII character 10, otherwise known as CTRL-A).
DOS and her derivatives use the two-character CR LF sequence to
indicate a new line and the C library performs automatic conversion
when a file is opened in text mode. Hence the need to open it in
binary mode instead.

This would be the case in most languages on the Windows platform.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net

 

[Nobuyoshi Nakada]

Hi,

At Sun, 11 May 2008 17:42:25 +0900,
Minic Hoberoff wrote in [ruby-talk:301446]:

So now the REAL question is, am I to blame or is Windows? (don't
answer that)

It's just a curse of CP/M. (sorry, but couldn't resist...

 

[7stud --]

Because he's not reading or writing 'a' (ASCII character 97) but the
linefeed character (ASCII character 10, otherwise known as CTRL-A).

I don't understand where the op is writing the LF character? It's
obvious from the file output that the op's ruby code must be trying to
write a '\n' to the file somewhere, which then gets converted to a
windows newline, which is a '\r\n', or 0A 0D in hex. But the op claims
to be entering an 'a' for input. The op's program then chomps() off any
newline. So where does the ruby code write a '\n' to the file?

 

[7stud --]

I don't understand where the op is writing the LF character? It's
obvious from the file output that the op's ruby code must be trying to
write a '\n' to the file somewhere, which then gets converted to a
windows newline, which is a '\r\n', or 0A 0D in hex. But the op claims
to be entering an 'a' for input. The op's program then chomps() off any
newline. So where does the ruby code write a '\n' to the file?

Furthermore, all that opening the file in binary mode does is prevent
newline conversions--it does not prevent newlines from being written to
the file. The result being that what gets written to the file is
exactly what you specify in your ruby code. Therefore, if the op's ruby
code is writing a '\n' to the file, then what will end up in the file
will be a '\n', or 0D in hex--which is still not an 'a'.

 

[Jeffrey 'jf' Lim]

[Note: parts of this message were removed to make it a legal post.]

Furthermore, all that opening the file in binary mode does is prevent
newline conversions--it does not prevent newlines from being written to
the file. The result being that what gets written to the file is
exactly what you specify in your ruby code. Therefore, if the op's ruby
code is writing a '\n' to the file, then what will end up in the file
will be a '\n', or 0D in hex--which is still not an 'a'.

Re-Read that original post again. And I do mean re-read it again. From the
top.

-jf

 

[Simon Krahnke]

Therefore, if the op's ruby code is writing a '\n' to the file, then
what will end up in the file will be a '\n', or 0D in hex--which is
still not an 'a'.

Well, that's '\r', '\n' is 0x0a or 'a'.hex.

mfg, simon .... l

 

[Vidar Hokstad]

I don't understand where the op is writing the LF character?

Hint: "a".hex == 10 decimal / 0x0a hex == LF

Vidar

 

[7stud --]

Hint: "a".hex == 10 decimal / 0x0a hex == LF

Vidar

Thanks.