7stud -- wrote:
> Eleanor McHugh wrote:
>> On 11 May 2008, at 09:58, 7stud -- wrote:
>>>
>>> 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).
> 
> 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'.



-- 
Posted via http://www.ruby-forum.com/.