bugGNU nano - Bugs: bug #54535, [Request] add search functionality...

 
 

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

bug #54535: [Request] add search functionality to command-line options

Submitter:  Derek <dwwolfe1>
Submitted:  Sat 18 Aug 2018 08:26:28 PM UTC
   
 
Severity:  1 - Wish Status:  Fixed
Assigned to:  bens Open/Closed:  Closed

Discussion locked!

Jump to the original submission

Sun 01 Sep 2019 12:42:36 PM UTC, comment #40: 

When finding a bug, please report it as a new issue.  In this case, I've done it for you: bug #56845.  Summary: I agree that +/string should find the first occurrence of "string", also when it's at the start of the file.  Specifying +/string on the command line is not the same as typing ^W string <Enter>, because for the latter the user can already see what is under the cursor.

Benno Schulenberg <bens>
Group administrator
Thu 29 Aug 2019 02:17:37 PM UTC, comment #39: 

Ok that makes sense if you think about it like opening a file and then doing ctrl+W to jump to the next match.  It may not be worth the trouble but I suppose it might be possible to make some special case that will consider a match at the beginning (or end?) of file only in the case of this searching feature?

Either way is fine for me.  At the moment I will just have to wrap around to make sure I catch the rare case where there's an immediate match at the beginning

Derek <dwwolfe1>
Thu 29 Aug 2019 04:36:18 AM UTC, comment #38: 

That is how nano's search functionality works, it just stands out more with this new feature. Open that same file, put cursor at top and try searching. It doesn't make sense to jump to the match the cursor is sitting on, and would probably break the ability to continue jumping between matches.

Placing the cursor at end of file for forward and backward searches would work, but it also displays "Search Wrapped" for the first forward match. Maybe clear statusbar after a forward search (from command-line) if it has a HUSH message.

Brand Huntsman <brand>
Wed 28 Aug 2019 08:14:15 PM UTC, comment #37: 

This feature is awesome, thank you for implementing it.  I installed v4.4 from source and have been putting it to use.  I noticed a small bug where it doesn't find a match that starts at the first character:

test.txt contains:
test 1
test 2
test 3

running the command:

nano +/"test" test.txt

finds the second instance of test instead of the first.  If there is only 1 instance of the keyword (or match starts on second character) it does find it properly.  Anyone else see this?

Derek <dwwolfe1>
Mon 26 Aug 2019 05:13:44 PM UTC, comment #36: 

Released in 4.4.

Benno Schulenberg <bens>
Group administrator
Sun 18 Aug 2019 11:12:45 AM UTC, comment #35: 

The main feature has been pushed to master in commit a9dd73fb, and the "crCR" search modifiers from Brand in commit 2326bf69 (slightly edited).

Benno Schulenberg <bens>
Group administrator
Sat 17 Aug 2019 10:17:06 PM UTC, comment #34: 

Ugh, I even knew about the infinite loop and forgot to add the default path. I also fixed the issue with rcRC not working with gotolinecolumn by simply changing the [1] to [n]. So +rc2,2 works if you want to toggle the modifiers and use gotolinecolumn.

It would also be quite easy to add "interactive" search and replace functionality with +rcs/search/replace/. A final 's' modifier could grab the next character for use as separator, grab searchstring until separator, and grab replacestring until separator or \0. Then it just needs a branch to search and replace if replacestring is set.

(file #47358)

Brand Huntsman <brand>
Sat 17 Aug 2019 01:07:15 PM UTC, comment #33: 

Thanks for the review.  Improved patch attached.

About the rcRC mode modifiers...  I think that's going a bit too far.  But... I've considered disabling regex searches entirely when searching at startup, but then M-W and M-Q wouldn't work or 'set regexp' would be invalidated.  I can hardly imagine that anyone would want to search for a regular expression at startup, but a case sensitive search... (and still have case insensitive as the default), yes, that I can imagine.  So adding the crCR modifiers will probably be unavoidable.

(Your patch, by the way, will hang if any other character than [crCR] is used after the + sign.)

(file #47355)

Benno Schulenberg <bens>
Group administrator
Thu 15 Aug 2019 01:51:22 AM UTC, comment #32: 

It will probably fail to compile without ENABLE_HISTORIES. The positionlog #endif needs to be moved up a line before the closing brace.

An empty search (src/nano +/ file) sets cursor to second character, but +? works fine. Detecting an empty query and not setting string fixes it.

Searching for a word not in the file results in "Search Wrapped" instead of a not found message.

When writing the documentation, you should mention that +/"1 2 .." and +/'1 2 ...' can be used to search for phrases with spaces. And +/'...' should always be used if the query contains a $ character.

--

Attached patch adds support to toggle case-sensitivity and regular expressions. +rc/ turns on both toggles and +RC/ turns off both toggles. Any combination of rRcC is allowed between the + and / or ?.

Using an empty query allows the default settings in nanorc to be overridden for the current instance without performing a search. It is free and avoids extra code to display an error message. But it doesn't work if gotolinecolumn from cli is also needed.

(file #47347)

Brand Huntsman <brand>
Fri 09 Aug 2019 01:39:49 PM UTC, comment #31: 

Attached is a second version of the patch that also works when having 'set regexp' in your ~/.nanorc file.

(file #47312)

Benno Schulenberg <bens>
Group administrator
Fri 09 Aug 2019 01:17:14 PM UTC, comment #30: 

Attached is a first implementation of the requested feature.  To open a file at the first occurrence of "someword", run:

  src/nano  +/someword  filename

To open it at the last occurrence:

  src/nano  +?someword  filename

Afterward, M-W and M-Q can be used to search for other occurrences.

The search is always case insensitive, unless you have 'set casesensitive' in your .nanorc.

(The search doesn't work when you have 'set regexp' in your .nanorc.  It will require a bit more hassle to get that to work.)

(file #47311)

Benno Schulenberg <bens>
Group administrator
Tue 04 Jun 2019 01:49:02 AM UTC, comment #29: 

Ok if it is just waiting based on priority that's good news for me because it will come eventually.  Thank you for the update

Derek <dwwolfe1>
Mon 03 Jun 2019 02:42:20 PM UTC, comment #28: 

Yeah, I've eyed this request once or twice during the past month.  But... other things to do.  There are still some optimizations that can be made that will increase performance for everyone.

Benno Schulenberg <bens>
Group administrator
Sat 01 Jun 2019 02:34:49 AM UTC, comment #27: 

Hello again, just checking on the status of this request because I would still very much like to use this feature.  It seemed like we agreed on a simple +/ and +? type implementation but it is still in postponed status and not assigned to anyone

Derek <dwwolfe1>
Tue 23 Oct 2018 02:35:33 PM UTC, comment #26: 

If +/ and +? are implemented, they would simply call 'findnextstr(thegivenstring, FALSE, JUSTFIND, NULL, TRUE, openfile->current, openfile->current_x)', which would not automatically add thegivenstring to the search history.  But yes, that is easy enough to make, and would be expected, so it would be done.

Benno Schulenberg <bens>
Group administrator
Tue 23 Oct 2018 05:22:00 AM UTC, comment #25: 

@Derek, it would call the same code used inside nano, so ya, the search query would be added to the history and the findnext and findprevious keys would work with it.

@Benno, I read Derek's comment thinking it was you asking if just -s would be okay. If possible, +/ and +? should both be added, even if +/ will be used far more often.

Brand Huntsman <brand>
Mon 22 Oct 2018 03:41:52 PM UTC, comment #24: 

The +/string and +?string implementation would work perfectly fine for me.  I'm assuming it would be possible to leave that keyword in the search buffer so I can move along to the next occurrence once inside the program

Derek <dwwolfe1>
Sun 21 Oct 2018 10:39:02 AM UTC, comment #23: 

Derek, we're talking only about a --find option (what you call -s).  The forms "+/string" and "+?string" are equivalent to it, only better, because they would work per file.  The -e or --execute or --implant options are off the table.

Brand, I can imagine backward searching (+?string) being used when it would mean: from tail of file.

Ondrej, the grep solution can be slightly improved by using -m1 with grep instead of the "| head -1".  (But the "head -1" has the advantage that it can be replace with "tail -1" to jump to the last occurrence instead.)

Benno Schulenberg <bens>
Group administrator
Fri 19 Oct 2018 02:25:08 AM UTC, comment #22: 

echo -n "^X" |nano NEWS

Anything other than ^X produces a lot of ERRs in read_keys_from().

echo "^X^Wfoo" |nano NEWS -

I thought maybe that would work but it looks like scoop_stdin() writes control characters to the buffer instead of evaluating them. That should probably be fixed.

Would -@ work instead of -s? It is a simple way to search and pairs with goto line, and should probably be supported, even if other more general options are added. I don't see backward search being used much.

The attached patch adds a -=/--implant=<str> option that does what -e would do. The patch is very raw and barely tested. The second file is a wrapper for an interactive search and replace.

(file #45242, file #45243)

Brand Huntsman <brand>
Thu 18 Oct 2018 02:26:21 PM UTC, comment #21: 

What if we reconsidered my original concept of something that applies specifically to search and does not address the more general functionality of your -e?  For example:

nano -s keyword filename

It looks like -s and -S are both currently in use so we would need a different letter.  But that new flag would only invoke the ^W search functionality on startup which should simplify the implementation.  That also allows the user to ^W to find subsequent matches and the keyword would already be loaded in there

Or another way:

echo "^Wkeyword^M" | nano -w test.txt

I like the second method as well (although it's more like -e) except you're leaving it up to the user to get it right.  I thought that might work but it crashed when I tried it.  Would it be easier to support pushing command strings into nano in this manner and would that be a viable option?

Derek <dwwolfe1>
Thu 18 Oct 2018 01:57:04 PM UTC, comment #20: 

Benno, yes,the grep solution is good enough for my scenario.
Good idea, Thanks!

Ondrej Zizka <pekarna>
Wed 17 Oct 2018 06:47:31 PM UTC, comment #19: 

The main reason for postponement is that there is no easy way to implement this.  The -e option (although easy to implement) is not clean enough.  The +/string and +?string manner looked easy, but it isn't.

However... with a little wrapper script one could make something close to it:

  #!/bin/sh
  # First argument should be search string, second the file name.

  nano +$(grep -n $1 $2 | head -1 | cut -d: -f1) $2

Especially for Ondrej this should be good enough, no?

Benno Schulenberg <bens>
Group administrator
Wed 17 Oct 2018 05:03:29 PM UTC, comment #18: 

Just so I'm clear, what are the developers opinions on this feature?  Is it that there's no easy or clean way to implement it?  Or it doesn't seem useful enough to be part of the main program?

I see that it has postponed status which implies it may be possible at some point?  If there's no hope of implementing something like this I will need to find another solution.  If it will eventually be done I can live with that

Derek <dwwolfe1>
Wed 03 Oct 2018 05:33:30 PM UTC, comment #17: 

Yes please. I vote for this. Would be a big help for most of my work scenarios (opening large configs at the right place).

Ondrej Zizka <pekarna>
Tue 11 Sep 2018 03:12:50 AM UTC, comment #16: 

It partially works. The following was used to benchmark file loading speed.

echo -n "^X" |nano test-file

Brand Huntsman <brand>
Mon 10 Sep 2018 07:55:16 PM UTC, comment #15: 

Another thought I had was to try piping a string into nano on startup.  Something like the following:

echo "^Wkeyword^M" | nano -w test.txt

I tried and it crashes so apparently that's not supported.  Does anyone know if it would be possible to send in commands and text in this manner?  This would work fine for me as well

Derek <dwwolfe1>
Mon 27 Aug 2018 04:28:40 PM UTC, comment #14: 

My immediate intentions are to use the search functionality however implemented to launch me directly to the first occurrence of a keyword from within a script.  At that point I would like to be able to ctrl+w and hit enter to search to the next hit if necessary.  All of that worked fine with this patch as is

In general I see the -e option as making nano a lot more amenable to scripting, or almost a type of macro operation where you can program in a bunch of operations.  For example I may be doing a semi-automated edit of a large number of files and want the script to automatically take me to the 3rd keyword match and then cut out that line and wait for me to take over and move that line somewhere else in the file.  Accomplishing that would be a matter of entering ^W^W^W^K or something similar in the script and it will run whatever convoluted thing I cooked up.  That gives a lot of interesting flexibility

I'm not interested in hacking this stuff out on the command prompt to run on a single file because it would be easier and faster to open the file and do the operations inside nano.  So this is something I see using in a script and in that case if it's mildly annoying to set up properly at least it only needs to be done once

Derek <dwwolfe1>
Mon 27 Aug 2018 12:06:50 AM UTC, comment #13: 

You should probably imagine -e supports function interpolation ("${justify}" vs "^[^J"), when thinking of useful examples for it.

Brand Huntsman <brand>
Sun 26 Aug 2018 09:08:26 PM UTC, comment #12: 

One thing I was thinking of using it for was justifying at least some of the file before opening it (since, given my recent work, I have justify on the brain :) ), but that's exposed one problem with the patch as-is, that I should have noticed before.

Specifically, there's no intuitive way to make it enter Ctrl-J, unless you're advanced enough to know that Ctrl-J is a newline.  (Although you'd have to be somewhat advanced to use this feature, as well.)

nano's verbatim input disables entering Ctrl-J, to avoid problems with interpreting newlines as nulls, so that's not an option.  I've tried entering it via mksh's vi-like verbatim input:

nano -e "<Ctrl-V><Ctrl-J>"

and it works.  I've also tried creating a shell script with


nano filename.txt -e "
"


and it works.  Still, that's another iffy part of using control characters directly.  If I want to justify the entire file, of course, entering "^[^J" works perfectly.

Is this enough of a problem, or do you consider it minor enough to not be?

I know I've waffled on this, but I'm torn when it comes to this feature's usefulness versus the interface to it.  For the record, if you go the other way with the search option, your proposals for +/ and +?, as well as position log behavior, do sound like good options to me.

David Lawrence Ramsey <dolorous>
Group Member
Sun 26 Aug 2018 10:38:06 AM UTC, comment #11: 

Derek, David, what else (apart from searching) could you imagine using the -e feature for?

I proposed the -e feature because it was easy to implement and it seemed like a more powerful mechanism.  But it is awkward to use and if all it will be used for is search for something at startup, then it would be better to implement a more specific mechanism.

(For searching backward I would propose +?, as "?" is what less and vim use to start a backward search.  When using +/ or +?, the position log does not need to be ignored because the user could specify with a preceding +1 or +-1 to start at the top or bottom of the file.)

Benno Schulenberg <bens>
Group administrator
Wed 22 Aug 2018 07:25:59 AM UTC, comment #10: 

Someone is working on function interpolation for string binds which is what this -e option uses. It will allow typing ${search} instead of ^W and ${enter} instead of ^M. And it still works if you bind search to another key, or a future version of nano rebinds it for you. Of course it does nothing if a future version of nano renames the function. If the -e feature is added, all function names will need to be locked from future renaming, otherwise any scripts that use the renamed function will break. Its one thing to rename a function that is only used in nanorc, but totally different when scripts depend on it.

Brand Huntsman <brand>
Wed 22 Aug 2018 04:50:38 AM UTC, comment #9: 

I like the functionality of the more general purpose execute command, it supports what I was originally asking for and also a lot more

In terms of the implementation, I could imagine allowing plain text as input to make it easier for the user to type out.  For example typing ^W as two standard characters instead of a special control character.  In my case I needed to do ctrl+v and ctrl+w at the bash prompt and esc+v and ctrl+w while editing a script (hurts my brain).  Not as easy to deal with in the code but it would make it easier from the user's perspective.  I had no clue how to enter those special characters and ended up activating every alt menu and pop up screen imaginable...

Obviously I think it's a useful feature since I asked for it, but it would be a shame if this never made it into nano releases.  Seems like a valuable addition to me

Derek <dwwolfe1>
Wed 22 Aug 2018 04:38:35 AM UTC, comment #8: 

You can jump to a position from command line, jumping to a word makes sense. If a cli search is used, position log should be ignored. It would also be nice if position log could be turned off entirely from the cli to prevent saving.

+/ could be a forward search from start of file and +\ a backward from end of file. If an initial position is given then both forward and backward start from that. Are there cli options to enable case-sensitive and regex searches? If not, the feature would need to provide a way, such an 'c' and/or 'r' between the + and slash.

Brand Huntsman <brand>
Wed 22 Aug 2018 04:20:12 AM UTC, comment #7: 

Although, after some more thought, the initial patch doesn't have either of the issues I brought up, since the nanorc options and +LINE,COLUMN would always work consistently for (1), and using Ctrl-Q via verbatim input would allow backward searches in (2).

So, I've changed my mind.  Even with the iffy bits, the initial patch would be better for those reasons.  It's a little more complex to work with (and would need to be well documented), but it can also do a lot more.

David Lawrence Ramsey <dolorous>
Group Member
Tue 21 Aug 2018 06:51:05 PM UTC, comment #6: 

It's interesting, but requiring control characters on the command line to use it is... iffy.

As for using an extension of the '+' argument to search, that seems much easier to work with.  Although I have a few questions about that hypothetical feature first:

1. If the "positionlog" command line or rcfile option is used, nano puts the cursor where it was when the file was closed.  Would using a '+/' option start a search from that position (which could vary considerably), or would it always start from the beginning of the file?  Unless you mixed the two types of '+' arguments, so that e.g.

nano +3,5 +/something

would start the search for "something" at line 3, column 5.

2. Would there be a way to control the direction of the search, in case you wanted to search backwards instead of forwards?  Other characteristics of the search can be controlled via command line or rcfile options, but backward searches are currently only available via an entirely different keystroke.

David Lawrence Ramsey <dolorous>
Group Member
Tue 21 Aug 2018 05:33:30 PM UTC, comment #5: 

True, it's not very intuitive, and not very convenient to use either.  Whether it will be added in a future version of nano... it doesn't seem like it, because no one has responded (yet) to the patch that I posted: http://lists.gnu.org/archive/html/nano-devel/2018-08/msg00045.html.

Maybe we should implement your suggestion instead, but then as extension of the + argument: if the + is followed by a slash, then nano should interpret what follows not as a line number but as a string to search for.

Benno Schulenberg <bens>
Group administrator
Tue 21 Aug 2018 02:52:59 AM UTC, comment #4: 

Ok I was able to get it working from script using Esc+v, ctrl+w, etc.  It does exactly what I was looking for so thank you for implementing.  My only concern is how intuitive it will be to use, although some good documentation would help with that.  Will this be added to future releases of nano?

Derek <dwwolfe1>
Mon 20 Aug 2018 06:43:38 PM UTC, comment #3: 

Copying and pasting with the mouse will not work, because it will copy what you actually see: ^W and ^M etcetera.  If you want to put those characters in a script, you have to edit the script with nano and enter those control characters by preceding them with M-V (the verbatim keystroke in nano, because ^V was used by Pico for PageDown).

Benno Schulenberg <bens>
Group administrator
Mon 20 Aug 2018 06:09:14 PM UTC, comment #2: 

That seems like a good idea, it would make this feature a lot more flexible.  I was able to compile, patch, and use the new version of nano which was something of a feat for me.  Entering the special characters ^W and ^M created the desired effect when running directly from the bash prompt

However, if I copy the exact same command into a shell script it doesn't work.  It seems to be because ^W and ^M are being interpreted as plain text instead of a special command??  Can you give an example of how I would run this from inside a script?  Or is it possible to trigger this behavior without needing these ctrl+ characters?

FYI I tested the following commands and they seemed to work which is great because you can actually do more than one operation (two searches in this case)

./nano -e ^Wkeyword^M test.txt
./nano -e "^Wkeyword^M^W^M" test.txt
./nano -w -e "^Wkeyword^M^W^M" test.txt

Derek <dwwolfe1>
Sun 19 Aug 2018 06:57:29 AM UTC, comment #1: 

How about the more general feature in the attached patch?

Searching at startup would then be done like this:

  nano -e ^Wkeyword^M  file.text

(where ^W and ^M are entered by preceding them with ^V).

(file #44810)

Benno Schulenberg <bens>
Group administrator
Sat 18 Aug 2018 08:26:28 PM UTC, original submission:  

I frequently run nano from scripts and would like to open a file and immediately search/seek to a keyword (similar to ctrl+w functionality).  Would it be possible to add this as a command line argument?

current usage:
- nano file.txt
- ctrl+w keyword

proposed usage:
- nano -s keyword file.txt

Derek <dwwolfe1>

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by pekarna (Posted a comment)
  • -email is unavailable- added by brand (Posted a comment)
  • -email is unavailable- added by dolorous (Posted a comment)
  • -email is unavailable- added by bens (Updated the item)
  • -email is unavailable- added by dwwolfe1 (nano search request)
  • -email is unavailable- added by dwwolfe1 (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 18 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-09-01 bens Discussion LockNone Locked
    2019-08-26 bens Open/ClosedOpen Closed
    2019-08-18 bens StatusIn Progress Fixed
    2019-08-17 brand Attached File- Added toggles-for-case-sensitivity-and-regular-expressions-when.patch, #47358
    2019-08-17 bens Attached File- Added 0001-new-feature-allow-specifying-a-search-string-to-jump.patch, #47355
    2019-08-15 brand Attached File- Added toggles-for-case-sensitivity-and-regular-expressions-when.patch, #47347
    2019-08-09 bens Attached File- Added 0001-new-feature-allow-specifying-a-string-to-jump-to-in-.patch, #47312
    2019-08-09 bens Attached File- Added 0001-new-feature-allow-specifying-a-string-to-jump-to-in-.patch, #47311
        StatusPostponed In Progress
        Assigned toNone bens
    2018-10-19 brand Attached File- Added 0001-implant-from-command-line.patch, #45242
        Attached File- Added nano-search-and-replace.sh, #45243
    2018-08-26 bens StatusReady For Test Postponed
    2018-08-19 bens Attached File- Added 0001-new-feature-option-e-for-specifying-commands-to-exec.patch, #44810
        Severity3 - Normal 1 - Wish
        StatusNone Ready For Test
        SummaryRequest - Add search functionality to command line arguments [Request] add search functionality to command-line options
    2018-08-18 dwwolfe1 Carbon-Copy- Added dwwolfe1

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code