bugGNU nano - Bugs: bug #56076, [Regression] nano 4.0 creates...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #56076: [Regression] nano 4.0 creates malformed text files by default

Submitter:  Dev Null <nnnn20430>
Submitted:  Fri 05 Apr 2019 12:33:31 AM UTC
   
 
Severity:  3 - Normal Status:  Duplicate
Assigned to:  None Open/Closed:  Closed

Tue 16 Apr 2019 08:42:24 AM UTC, comment #5: 

The fix has been released in 4.1.  Thanks for reporting.

Benno Schulenberg <bens>
Group administrator
Sun 07 Apr 2019 08:11:35 AM UTC, comment #4: 

Fixed in git, commit 25523070.  It will be released in version 4.1 in about ten days time.

Benno Schulenberg <bens>
Group administrator
Fri 05 Apr 2019 01:56:01 PM UTC, comment #3: 

Great, thank you!

I also want to respond to something you said in the mailing list:

> So, if I have some characters, say "foo", arranged into zero lines
> (meaning that there is no newline character at the end), then it is
> perfectly a text file.  No?


The definition of a text file in POSIX, does not specify the existence of characters
outside of those organized in lines, zero lines means empty file,
because zero characters can be organized in zero lines.

POSIX "Rationale for Base Definitions" clarifies this:
"The definition allows a file with a single <newline>, or a totally empty file, to be called a text file. If a file ends with an incomplete line it is not strictly a text file by this definition."

Dev Null <nnnn20430>
Fri 05 Apr 2019 08:12:20 AM UTC, comment #2: 

No worries -- it is easy enough to mark something as a duplicate; disentangling two issues from a single report is much more work.

Yes, nano will go back to adding an automtic newline when the user starts typing.  See http://lists.gnu.org/archive/html/nano-devel/2019-04/msg00019.html.  Thanks for the report and the examples.

(Two small notes.  One, 'wc' does not _discard a string of characters that is not terminated by a newline: it _does count the words and characters in it, it just doesn't count it as a line.  Two, that the cursor can always go down to an empty final line (when the automatic newline is added) is a convenience thing: having to go to the end of the last line and then type <Enter> before you can add another line to the text is un-userfriendly.)

Benno Schulenberg <bens>
Group administrator
Fri 05 Apr 2019 12:39:37 AM UTC, comment #1: 

Only after I submitted this did I manage to find that there was a related bug report (bug #55997). I'm sorry.

Dev Null <nnnn20430>
Fri 05 Apr 2019 12:33:31 AM UTC, original submission:  

Preamble:
POSIX defines a line as "A sequence of zero or more non-<newline> characters plus a terminating <newline> character."
This definition has practical value. The guarantee that each line in a text file ends with a terminator
makes parsing, viewing and manipulating text files easier and more predictable.

I have recently updated nano, and I quickly noticed that it is creating text files
with an unterminated final line, leading to various problems. These include:

 When I try to view a file created with nano 4.0 in a terminal directly using cat,
 the unterminated text at the end of file spills into the beginning of the shell prompt.

 When I try to concatenate it with another text file,
 the two files are improperly merged, resulting in a jumbled line.

 Many programs (such as wc -l) will not parse files produced by nano 4.0 correctly,
 discarding the unterminated line.

Even before this change to 4.0, I believe nano handled line endings incorrectly.

Nano would allow you to simply move the cursor down onto a "new line" after the last.
This indicates an understanding of the <newline> character not as a line terminator, but as a line separator.

I think this is wrong.

Nano should only allow the cursor to move to an existing line, which may be an empty line,
defined by POSIX as "A line consisting of only a <newline>".
This excludes the aforementioned case, where the line is completely empty,
thus it cannot be considered a line in the POSIX definition.

It may, of course, be useful to edit a non-textual (binary) file, where terminating lines wouldn't make sense.
For this there should be a binary format, to go along with the DOS and Mac formats.
This format should be automatically activated when no other formats properly apply.
When saving in Unix format, nano should always write a <newline> character at the end of every line.

I am aware that many people may not have encountered the notion that the <newline> character is a line terminator,
not a line separator, and may dislike this behaviour.
However, I believe nano should follow POSIX for the sake of compatibility and sanity.

Dev Null <nnnn20430>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by bens (Posted a comment)
  • -email is unavailable- added by nnnn20430 (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-04-16 bens Open/ClosedOpen Closed
    2019-04-05 bens StatusNone Duplicate

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code