bugGNU nano - Bugs: bug #55997, to protect novices, nano should...

 
 

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

bug #55997: to protect novices, nano should produce files with POSIX lines by default

Submitter:  Benno Schulenberg <bens>
Submitted:  Mon 25 Mar 2019 01:24:49 PM UTC
Votes: 12
 
Severity:  3 - Normal Status:  Fixed
Assigned to:  bens Open/Closed:  Closed

Jump to the original submission

Tue 16 Apr 2019 08:41:51 AM UTC, comment #7: 

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

Benno Schulenberg <bens>
Group administrator
Sun 07 Apr 2019 08:09:57 AM UTC, comment #6: 

The behavior has been reverted in git, commit 25523070.

(For completeness: a duplicate report was filed in bug #56076.)

Benno Schulenberg <bens>
Group administrator
Fri 05 Apr 2019 04:17:48 AM UTC, comment #5: 

Having looked into emacs further, even it enables terminating final lines,
when it is editing well known textual files like .txt or .c.
I still think it should default to terminating final lines,
unless it detects non textual files.

So with that, nano is again the only editor I know, which creates malformed text files by default.

Dev Null <nnnn20430>
Fri 05 Apr 2019 03:12:14 AM UTC, comment #4: 

While gnu coreutils, may be hardened against non terminated last lines,
because they are supposed to be portable, and some systems use line separators instead of terminators.
I personally had no reason to assume any program I ever wrote for personal use,
which does any kind of manual line aware parsing, would ever encounter a non terminated line.

This is because POSIX clearly states that every line must be terminated by a newline character.
And up until now, I have never encountered a single editor or any program which generates
text output, that did not have every line terminated.
Because of this all of my programs discard everything after the last newline character.

Due to this strange nano change, I did discovered that emacs also doesn't
terminate the last line by default, this is surprising and unexpected.

Dev Null <nnnn20430>
Sun 31 Mar 2019 02:34:35 AM UTC, comment #3: 

Try using "cat file1 file2" when file1 doesn't have a final newline, it can break scripts which parse concatentated files. And "cat file1" doesn't advance prompt to next line. And both "cat file1 |wc -l" and "wc -l file1" return 0.

Brand Huntsman <brand>
Mon 25 Mar 2019 06:01:11 PM UTC, comment #2: 

Can you give three or more examples of Unix programs that mistreat or fail to treat an unterminated final line?  Because if it's just one or two outlier programs that have a problem with such a line, it isn't worth the trouble.

Benno Schulenberg <bens>
Group administrator
Mon 25 Mar 2019 02:01:42 PM UTC, comment #1: 

Thanks for opening the bug Benno, and subscribing me, I would have gotten around to doing it myself eventually.

Ralph Corderoy <ralph>
Mon 25 Mar 2019 01:24:49 PM UTC, original submission:  

(Originally posted by Ralph Corderoy, in bug #55067.)

> I've arrived here due to 4.0's announcement saying:
>
> "A newline character is no longer automatically added at
> end of buffer."
>
> If that means the 'text' file that's written doesn't always
> have an ASCII linefeed terminating the last line of text
> then that breaks POSIX.
>
> POSIX defines a text files as zero or more lines of
> characters, each terminated by an ASCII LF. Thus, the
> non-Unix Emacs style of text file that writes "1\n2\n3"
> to a file instead of "1\n2\n\3n" is not a POSIX text file.
>
> Many Unix programs, especially those not from the GNU
> school, treat these incorrect text files in surprising
> ways, e.g. ignoring the unterminated final 'line'.
> Experienced users can spot the problem. Inexperienced
> users, as many nano users probably are, will be foxed
> by it and should be protected by always writing POSIX
> text files by default, just as other Unix editors do,
> e.g. ed(1), and vi(1).

Benno Schulenberg <bens>
Group administrator

 

(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 nnnn20430 (Posted a comment)
  • -email is unavailable- added by nnnn20430 (Voted in favor of this item)
  • -email is unavailable- added by brand (Posted a comment)
  • -email is unavailable- added by faxanadu (Voted in favor of this item)
  • -email is unavailable- added by ralph (Posted a comment)
  • -email is unavailable- added by bens (Submitted the item)
  • -email is unavailable- added by bens
  •  

    There are 12 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 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-04-16 bens Open/ClosedOpen Closed
    2019-04-07 bens StatusNone Fixed
    2019-04-05 bens Assigned toNone bens
        Summaryto protect novices, nano should produce POSIX text files by default to protect novices, nano should produce files with POSIX lines by default
    2019-04-05 nnnn20430 Carbon-Copy- Added nnnn20430
    2019-03-26 faxanadu Carbon-Copy- Added faxanadu
    2019-03-25 bens Carbon-Copy- Added ralph

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code