Re: [chirp_devel] Files with CRLF vs. LF vs. CR?
On 14-11-09 03:00 PM, chirp_devel-request@intrepid.danplanet.com wrote:
Date: Sat, 8 Nov 2014 14:15:01 -0800 From: Tom Hayward tom@tomh.us Subject: Re: [chirp_devel] Files with CRLF vs. LF vs. CR? To: "chirp_devel@intrepid.danplanet.com" chirp_devel@intrepid.danplanet.com Message-ID: CAFXO5Z3k49=TN0ZXqAn3fn3YiUeJkGNN0ehZCHR+uQt86Eg1HA@mail.gmail.com Content-Type: text/plain; charset=UTF-8
...
The stock_configs are CSV files, not Python source files. They have different requirements.
Agreed, I only thought to try to make all the stock_configs use a consistent line termination. If your thoughts are that this is much too risky, I can easily skip making this change.
You also mentioned testing below but I didn't see any tests relating to stock_configs. Would it be worth me raising a ticket to add tests that try to load each csv file in the stock_configs directory maybe or is this just another example of something that doesn't need fixing?
When Chirp reads CSV files, \n, \r, or \r\n are translated to \n. On write, \n is translated to the system default line separator, os.linesep. (This is built-in behavior for Python's CSV module, not something we're doing explicitly.)
Thank you for the clarification. I wasn't really concerned about the internal or output line termination used by Chirp. I merely pointed out that the stock_configs were produced using a variety of programs such as LibreOffice and Excel and so on and was offering to make them look more alike. Again, it sounds like this change to the stock_configs is not wanted so problem solved!
Open the CSV in Chirp, edit something, and save it. That'll tell you which line endings are appropriate for your system.
I seem to always get DOS-formatted files output from Chirp on my Ubuntu system using the daily builds. I shall start watching more carefully for this behaviour now. So far, I've only used Chirp and generated csv files for Chirp on Linux systems.
Once I know for sure, I shall be raising another bug/ticket/issue/whatever to give all the rest of the stock_configs files the same line terminators.
There's no need to change something that isn't broken. You'll have to convince us that there is some benefit to this change.
No convincing will be necessary. However, should I still attempt to resolve issue #1995--without altering the line terminators--and only reorder the entries as they aren't technically broken? If yes, I will complete applying the patch. If not, may I simply reject issue #1995?
People use Chirp CSV files in a lot of different editors. Chirp, Notepad, Excel, LibreOffice, etc., all work fine now. That's a long list of tests that would need to be done to accept a change.
Tom KD7LXL
Hmm... I don't recall seeing a list of supported external CSV editors. Should this be added to the wiki?
Tyler VA3DGN
On Sun, Nov 9, 2014 at 1:27 PM, Tyler Tidman tyler.tidman@draak.ca wrote:
Open the CSV in Chirp, edit something, and save it. That'll tell you which line endings are appropriate for your system.
I seem to always get DOS-formatted files output from Chirp on my Ubuntu system using the daily builds. I shall start watching more carefully for this behaviour now. So far, I've only used Chirp and generated csv files for Chirp on Linux systems.
That's Python's CSV module attempting to build files that are compatible with as many systems as possible. Let that be your guide: if you want to standardize CSV files to a specific line terminator, it looks like DOS format is most appropriate.
People use Chirp CSV files in a lot of different editors. Chirp, Notepad, Excel, LibreOffice, etc., all work fine now. That's a long list of tests that would need to be done to accept a change.
Hmm... I don't recall seeing a list of supported external CSV editors. Should this be added to the wiki?
If you test some third-party CSV editors and find them to work with Chirp files, you can document this on the wiki. I wouldn't go so far as to say they're "supported", just "known to work". If there are any caveats with any of them, you could document this in the same place. I seem to recall there being some issue with how Excel handled empty fields, but I don't recall the details--this would be a perfect thing to document.
Tom KD7LXL
On 11/9/2014 5:15 PM, Tom Hayward wrote:
I seem to recall there being some issue with how Excel handled empty fields, but I don't recall the details--this would be a perfect thing to document.
The issue I've seen with CSV files saved from Excel is that Excel doesn't preserve the number of columns when there are a number of empty columns at the end. In other words, the list of ',,,,,,' you'd expect to see at the end of the lines are missing.
participants (3)
-
Robert Terzi -
Tom Hayward -
Tyler Tidman