| Summary: | new line at the end of ascii file | ||
|---|---|---|---|
| Product: | [Applications] kst | Reporter: | Grégoire Verlut <gregoire.verlut> |
| Component: | general | Assignee: | kst |
| Status: | RESOLVED INTENTIONAL | ||
| Severity: | wishlist | CC: | netterfield |
| Priority: | NOR | ||
| Version: | 2.0.0 | ||
| Target Milestone: | 2.0.0 | ||
| Platform: | unspecified | ||
| OS: | Microsoft Windows | ||
| Latest Commit: | Version Fixed In: | ||
|
Description
Grégoire Verlut
2009-12-15 19:13:20 UTC
A primary application of kst is with dynamically expanding data files. If kst grabs a data file in the middle of a line being written, then it could be reading a partial line, and not know it. eg, last line as it will eventially be 1.0 23.45E-10 last line as kst happens to get it when it happens to read the file: 1.0 23.4 This would cause great troubles. If we demand that the lines end with a new line, then we avoid this problem. Even delaying, and checking back won't work, because the file could be coming from the end of a buffered pipe, in which case, the delays could be long and unpredictable. I'm leaning towards 'wont fix' unless someone can come up with a solution. Barth, I think that makes sense. I don't see any way to handle the "wrong timing" issue either, so I'd say the least bad solution is to leave as is, and let people who have fixed files without the final CR to add it... Grégoire ? That was my fearing when I reported this wish. Ok for closing the bug as "wont fix because not a bug" (maybe have an entry in the help that will come one day) Grégoire Closing as wontfix, as per discussion... Change version from 2.0.0_devel to 2.0.0 to simplify version numbering. These bugs are solved with 2.0.0 |