id summary reporter owner description type status priority milestone component version resolution keywords cc blockedby blocking branch_state votes 46 savannah: mcedit forgets POSIX newline at end of file slavazanko "Original: http://savannah.gnu.org/bugs/?16452 ||Submitted by:||Rudolf Polzer ||Submitted on:||Thu 27 Apr 2006 07:27:54 AM UTC|| ||Category:||None||Severity:||3 - Normal|| ||Status:||None||Privacy:||Public|| ||Assigned to:||None||Open/Closed:||Open|| ||Release:||4.6.1||Operating System:||GNU/Hurd|| Discussion: {{{ Wed 21 Jun 2006 05:36:17 PM UTC, comment #7: Any patches forthcoming? Leonard den Ottolander Project Member Sat 29 Apr 2006 09:18:23 AM UTC, comment #6: I think such a dialog box should rather read: The file you are editing does not end with a newline as required by many programs. Do you want to add one? [Yes] [No] and - since mcedit is suitable for editing binaries - it would not hurt if ""No"" was the by default selected button. But a method to warn the user via some red highlighting would also suffice I think... the main reason is that I often read about complaints from users who edited their files with mcedit - and then the program (again, sudo and gcc are the most prominent examples) fails to work with the file (sudo, and there is no indication in the error messages about what is wrong) or outputs a warning the clueless user does not understand (in case of gcc - although I think gcc's warning is clear enough). Rudolf Polzer Sat 29 Apr 2006 08:25:21 AM UTC, comment #5: ... except that this patch does not actually handle the Cancel case ... but other than that i'm fine with it. Oswald Buddenhagen Sat 29 Apr 2006 08:12:29 AM UTC, comment #4: mcedit is currently suitable for editing binary files, too. I wouldn't like to give up this feature. So we had to do something like: if (the current file looks like a text file) { if (edit->size > 0 && get_byte(edit->size) != '\n') { if (inputbox(""This file does not end with a newline. "" ""Shall we add it?"", YES|NO|CANCEL) == YES) { edit_insert_byte(edit->size, '\n'); } } } Roland Illig Project Member Thu 27 Apr 2006 09:50:09 PM UTC, comment #3: Damn, why does it say GNU/Hurd there? I'm quite sure that I didn't select that on purpose (I'm using GNU/Linux and FreeBSD), maybe I just clicked next to the right choice... please change that or ignore it, thanks. Rudolf Polzer Thu 27 Apr 2006 09:47:52 PM UTC, comment #2: Sorry, I forgot to quote the definition of ""line"" too... 3.205 Line A sequence of zero or more non-s plus a terminating . http://www.opengroup.org/onlinepubs/000095399/basedefs/xbd_chap03.html However, another solution would be using syntax highlighting to highlight a missing newline at the end of the file if it is known that a file format requires it (just like Makefiles are handled when a line starts with eight spaces). And since many tools get quite irritated if the newline is missing (another prominent example is ""cat"" - people often wonder why the shell prompt gets in the same line as the file data - and then of course some old versions of vi and less that I've seen on some older UNIX systems), it would be good to at least highlight the missing newline even by default. Rudolf Polzer Thu 27 Apr 2006 04:05:23 PM UTC, comment #1: nothing in the quoted paragraph suggests that a newline has to be present. there are two philosophies regarding newlines: newlines as line terminators (requires newline) and newlines as line breaks (separators - no newline required). personally, i also lean towards line termination. however, so far mcedit follows a ""don't do anything not explicitly requested"" philosophy (autoindent being the exception) - not necessarily by design, but because it is simpler to implement. but i'd argue that the ""explicit"" mode is a good default choice anyway. as far as dos newlines are concerned, i repeatedly found it annoying that mcedit can't deal with them (displaying ^M does not count ;). i think it should handle them transparently - and possibly offer a conversion option. Oswald Buddenhagen Thu 27 Apr 2006 07:27:54 AM UTC, original submission: When editing a file, mcedit does not put a newline character at the end of the file as required by POSIX and other standards. I quote IEEE 1003.2-2001: A file that contains characters organized into one or more lines. The lines do not contain NUL characters and none can exceed {LINE_MAX} bytes in length, including the . I think a text editor should default to the OS's text file format which does require a newline at the end of the last line (many utilities including sudo actually require that and gcc warns if the last line does not end with a newline). Of course, if one is editing a DOS file (CRLF line separators), no newline is to be enforced. }}} " enhancement new major mcedit