On Thu, Oct 28, 2010 at 3:23 PM, <[email protected]> wrote:
> On Thu, Oct 28, 2010 at 2:40 PM, Darren Dale <[email protected]> wrote:
>> On Thu, Oct 28, 2010 at 12:23 PM, <[email protected]> wrote:
>>> On Thu, Oct 28, 2010 at 12:11 PM, Charles R Harris
>>>> On Thu, Oct 28, 2010 at 9:23 AM, Darren Dale <[email protected]> wrote:
>>>>> And now the bad news: I have not been able to verify that Git respects
>>>>> the autocrlf setting or the eol setting in .gitattributes on my
>>>>> windows 7 computer: I made a new clone and the line endings are LF in
>>>>> the working directory, both on master and in my whitespace-cleanup
>>>>> branch (even the nsi.in file!). ("git config -l" confirms that
>>>>> "core.autocrlf" is "true".) To check my sanity, I tried writing files
>>>>> using wordpad and notepad to confirm that they are at least using
>>>>> CRLF, and they are *not*, according to both python's open() and grep
>>>>> "\r\n". If it were after noon where I live, I would be looking for a
>>>
>>> maybe just something obvious: Did you read the files in python as binary
>>> 'rb' ?
>>
>> No, I did not. You are right, this shows \r\n. Why is it necessary to
>> open them as binary? IIUC (OIDUC), one should use 'rU' to unify line
>> endings.
>
> The python default for open(filename).read() or open(filename,
> 'r').read() is to standardize line endings to \n.
Although, on a mac:
In [1]:
open('tools/win32build/nsis_scripts/numpy-superinstaller.nsi.in').readlines()[0]
Out[1]: ';--------------------------------\r\n'
_______________________________________________
NumPy-Discussion mailing list
[email protected]
http://mail.scipy.org/mailman/listinfo/numpy-discussion
