You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Bug .GCT written by cmapPy on Windows have inconsistent line endings #77
#Bug .GCT files written with cmapPy on Windows, show alternating blank lines after the top 3 lines when opened in Excel, though fine in code editor Spyder v5.12.3
Fix: The line below writes the 1st 2 lines of a .GCT file and would otherwise default to OS line_terminator of \r\n which conflicts with all other lines terminated by \n
Inconsistent line endings probably tricks Excels auto line ending recognition
Won't that lead to \r\n line endings on Windows? We should be striving to get the entire file to be \n line endings. I seek to have a file that is identical, no matter whether it is written in linux or windows. That is how I encountered this bug.
I understand your point, but I feel that it would be wise to follow the convention chosen by pandas to use system-specific line terminators. I confirmed (on my Mac) that the file looks the same when opened in Excel if all the terminators are either all \n or all \r\n.
I'm a Windows guy and now-a-days Windows programs can routinely handle '\n' line terminators. For reading/writing .GCT files people upstream/downstream of me use Macs. Consequently it is important to be able to read/write and get the same result. If you force windows generated files to be '\r\n' then I'm going to have fix every one I produce with cmaPy to get the desired '\n'.
Would you please at least provide an option to specify the line terminator to be written? So long as I have a means to get '\n' then I don't care which you choose as a default.
Activity
levlitichev commentedon Sep 12, 2022
Good catch. I think the better change would be to replace
\nwithos.linesepinwrite_version_and_dims:cmapPy/cmapPy/pandasGEXpress/write_gct.py
Lines 64 to 65 in d1652c3
KarlClauser commentedon Sep 12, 2022
Won't that lead to \r\n line endings on Windows? We should be striving to get the entire file to be \n line endings. I seek to have a file that is identical, no matter whether it is written in linux or windows. That is how I encountered this bug.
--Karl
levlitichev commentedon Sep 12, 2022
I understand your point, but I feel that it would be wise to follow the convention chosen by
pandasto use system-specific line terminators. I confirmed (on my Mac) that the file looks the same when opened in Excel if all the terminators are either all\nor all\r\n.KarlClauser commentedon Sep 12, 2022
Hi Lev,
I'm a Windows guy and now-a-days Windows programs can routinely handle '\n' line terminators. For reading/writing .GCT files people upstream/downstream of me use Macs. Consequently it is important to be able to read/write and get the same result. If you force windows generated files to be '\r\n' then I'm going to have fix every one I produce with cmaPy to get the desired '\n'.
Would you please at least provide an option to specify the line terminator to be written? So long as I have a means to get '\n' then I don't care which you choose as a default.
Thanks,
--Karl