bugGNU nano - Bugs: bug #52399, consecutive ones are not always...

 
 

bug #52399: consecutive ones are not always displayed (i.e., 1111111 is displayed as 1)

Submitted by:  None
Submitted on:  Mon 13 Nov 2017 08:46:54 AM UTC  
 
Severity: 3 - NormalStatus: Invalid
Assigned to: NoneOpen/Closed: Closed

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Tue 14 Nov 2017 07:33:17 PM UTC, comment #3:

Thanks for reporting back. So... this appears to be an absurd iTerm2 bug. :|

(I would mark this report as "Not our bug", but Savannah doesn't know that resolution.)

Benno Schulenberg <bens>
Project Administrator
Tue 14 Nov 2017 10:31:24 AM UTC, comment #2:

My preparation for this bug report was indeed sloppy; the bug seems to occur only when I use iTerm2. This is not a nano bug. Sorry for the inconvenience.

/*
I'll still answer the questions:
1 (nano --ignore) Yes
2 (identical file) Yes
3 (how many ones) At the moment 7 ones -> 1 one
4 (what terminal) iTerm2 (echo $TERM: xterm-256color; echo $SHELL: /bin/bash)
5 (file format) Mac
6 (filename) test2.m
7 (different filename) does not change the bug

Today the bug works as follows in iTerm2: when exactly seven ones appear, six of the ones are not displayed, i.e., the line "A=0b111111101111111" is displayed as "A=0b101", although the missing characters are actually editable, they are just not visible. The native Mac program Terminal displays things correctly.
*/

Anonymous
Mon 13 Nov 2017 07:43:50 PM UTC, comment #1:

When you use 'nano --ignore", do you get the same result? If you create an identical file in another editor, and open it in nano, do you get the same erroneous result? How many ones get transformed to a single one? (Because itis twelve to one, and in the headline it is five to one.) What terminal are you using? What file format are you using (does it say Mac when you type ^O)? Under what filename do you save the file? If you save it under a different name...?

As you can imagine, this doesn't sound like a bug in nano. Nano shouldn't munge any contents of a file.

Benno Schulenberg <bens>
Project Administrator
Mon 13 Nov 2017 08:46:54 AM UTC, original submission:

Noticed this while programming on GNU Octave on a Mac (OSX10.11 El Capitan). GNU Nano 2.8.7 installed through MacPorts. To reproduce the bug, create and save a file in Nano with the two lines

A = 0b111111111111;
B = 0b1111;

Then exit Nano, and open the file again to see

A = 0b1;
B = 0b1111;

Anonymous

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by bens (Posted a comment)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 16 Nov 2017 06:02:56 PM UTCbensOpen/ClosedOpen=>Closed
    Tue 14 Nov 2017 07:33:17 PM UTCbensStatusNeed Info=>Invalid
      Summaryconsecutive ones are not always displayed (i.e., 11111 is displayed as 1)=>consecutive ones are not always displayed (i.e., 1111111 is displayed as 1)
    Mon 13 Nov 2017 07:43:50 PM UTCbensStatusNone=>Need Info
      SummaryConsecutive ones not always displayed (i.e., 11111 is displayed as 1)=>consecutive ones are not always displayed (i.e., 11111 is displayed as 1)

    Back to the top


    Powered by Savane 3.1-cleanup1