1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 <2008> 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 <2008> 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: Initialize multi-element field |
From: | Maren Purves <[email protected]> |
To: | [email protected] |
Cc: | [email protected] |
Date: | Fri, 29 Feb 2008 09:02:21 -1000 |
On Wednesday 27 February 2008 22:52, Maren Purves wrote:Andrew Johnson wrote:Benjamin Franksen wrote:Similar remarks apply, BTW, to other EPICS tools. For instance, I noticed in the past that dbExpand silently ignores the last line of a dbd include file if it doesn't end in a newline. This has caused endless grief to Windows users, as editors for Windows generally don't automatically add a newline at the end.
If this hasn't already been fixed, I propose to put it on the list of things to be done before the next release of base. I'd say chances that people rely on the faulty behaviour are practically zero.I would have no problem in including a fix for that in base, I just can't see how to modify dbStaticLib to do it myself. Patches from Flex/Antelope experts welcomed.IMHO they should fix windows rather than that we should break something else to accommodate it.
Maren:
I have two questions:
(1) How exactly does 'something else' break if we fix this (which I regard as a bug) in dbStaticLib?
(2) Do you really regard it as correct behaviour (and rather think Windows is broken) if a tool that processes a text file silently ignores the last line whenever it misses a trailing newline? Note that this last line is visible in /any/ text editor or text viewer on any platform. It is merely a /convention/ that (many, not all) Unix editors automatically add a newline when the file is saved.
Lines should end in a newline character. IMHO it's part of what a line is. Saving the space that the newline character occupies may have been an issue when disk space was expensive and people were communicating on 1200 baud modem lines, but it shouldn't be now.
I guess this goes in the direction of 'once FITS always FITS' - and I'm well aware of that we're not talking about FITS here and that a lot of the people in the EPICS community don't know what FITS is. It's always been that way, and we should keep it backwards compatible.
I'm not saying we should necessarily keep ignoring the last line if it misses the newline character, but we should have newline characters on the ends of all lines.