bugGNU nano - Bugs: bug #63034, no search string should ever match...

 
 

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

bug #63034: no search string should ever match the magic line

Submitter:  Benno Schulenberg <bens>
Submitted:  Thu 08 Sep 2022 02:51:51 PM UTC
 
Severity:  2 - Minor Status:  Fixed
Assigned to:  bens Open/Closed:  Open

Mon 12 Sep 2022 07:01:08 AM UTC, comment #3: 

Fixed in git, commit 50954a4b, by requiring that for a valid match there must be a next line OR there must be data on this line.  This is because the final, empty line in a buffer (if any) is an artifact of nano: the preceding newline character makes nano create a fresh, empty linestruct, even when in the file itself nothing more follows.

Benno Schulenberg <bens>
Project Administrator
Fri 09 Sep 2022 10:58:13 AM UTC, comment #2: 

Improved patch is attached.  This brings nano's behavior in line with the behavior of Vim and Emacs.

(file #53669)

Benno Schulenberg <bens>
Project Administrator
Thu 08 Sep 2022 03:07:39 PM UTC, comment #1: 

Attached patch fixes the problem.

(After application, four lines at the end of do_replace_loop() can be deleted, as now nothing will ever be replaced on the magic line.)

(file #53663)

Benno Schulenberg <bens>
Project Administrator
Thu 08 Sep 2022 02:51:51 PM UTC, original submission:  

(Original report by Mike Scalora in https://lists.gnu.org/archive/html/nano-devel/2022-09/msg00003.html.)

When searching for something (or replacing something), nano cannot search for the empty string, so a literal string will never match the empty magic line at the end of the buffer.  But... when using a regex search, there are several regexes that can match an empty string and these will thus match with the magic line.  But this match is wrong, because in fact there is no line there, there is nothing there.  This magic line exists for two reasons: 1) to allow the user to type <Down> or <PageDown> or similar and be certain to arrive on the bottom line of the file, after all lines with text, without having to type <Enter> first; and 2) to prevent the user from accidentally creating a non-POSIX file where the final string of characters are not terminated by a newline (as such an unterminated line may be incorrectly handled by some tools).

So... the fact that a regex like ^ or $ has matched with the magic line since about the beginning of time... is a bug.

Benno Schulenberg <bens>
Project Administrator

 

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

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by bens (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 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-09-12 bens StatusReady For Test Fixed
    2022-09-09 bens Attached File- Added 0001-search-skip-a-match-on-the-magic-line-as-it-is-a-jus.patch, #53669
    2022-09-08 bens Attached File- Added 0001-search-skip-any-match-on-the-magic-line-as-it-is-a-v.patch, #53663
        Severity3 - Normal 2 - Minor
        StatusNone Ready For Test

    Back to the top


    Powered by Savane 3.9