Menu
▾
▴
#36 Command Line Parameter "--search"
Hi there,
I've been using docfetcher for quite a while and really enjoy it.
Since I also use Launchy I wonder if one can pass a search string as a command line argument to start searching documents from within launchy.
I searched the wiki, the sf forums and any available help resource but couldn't find any hints if this is possible and which parameters are to be used.
My feature request is:
Please add support for a search string to be past as an argument when starting docfetcher.
If such a feature already exist, please make this information available in documentation and help resources.
I use docfetcher portable on win xp.
Thanks and keep up the good work!
justfortherec
DocFetcher doesn't support this (yet), but technically it shouldn't be much of a problem.
Could you explain why you need something like this, please? A concrete example would be helpful.
This is because, before we can implement anything, we need to fully understand what we're doing and why.
Hi,
thanks for your prompt response.
I use Launchy (https://sourceforge.net/projects/launchy/) as an application launcher and want to use it to initiate searches with docfetcher.
Ideally docfetcher would accept start parameters like docfetcher.exe /q "words to search in documents" for Launchy to be able to pass those arguments to docfetcher.
Docfetcher would then start (or show up if already running) and show a list containing "words to search in documents".
Additional arguments could be accepted to define search scope, file types, etc.
DocFetcher has a hotkey (Ctrl+F8 by default), so you could start it, minimize it into the system tray and bring it back with the hotkey anytime you want. Isn't this what you want?
thanks for that tip. this might work if (a) docfetcher is already running (which it is not by default on my system; I prefer just starting it when I need it) and (b) if I was able and willing to memorize that additional hotkey. Since I am lazy and don't want to learn new stuff I prefer starting all searches (either for applications or documents or anything else) from one place - that's my app launcher :-)
My steps to search for a document are
1) Hit Ctrl + Space to open launchy
2) Enter "docfetcher"
3) Hit Enter
4) Wait for docfetcher to start
5) Enter searchterm
6) Hit Enter
6) Wait for docfetcher to display results
If docfetcher accepted start parameters the steps were as follows:
1) Hit Ctrl + Space to open launchy
2) Enter "docfetcher"
3) Hit Tab
4) Enter searchterm
5) Hit Enter
6) Wait for docfetcher to display results
I realize that there is just one step saved but it would be much more convenient.
This said (and tested) I have an additional request: Is it possible to bring forward an running instance of docfetcher instead of opening a second instance if one starts docfetcher while having it already running?
This could be achieved by another parameter. If each new search initiated from Launchy would open another instance of docfetcher those multiple instances would soon be annoying.
Okay, then how about something like this:
docfetcher.exe --search "Some search terms"
Filtering, sorting and other fancy stuff shouldn't be done via the command line (too complicated).
The problem with the multiple instances will probably be fixed in a future release.
Thanks for the effort!
For your information, we're currently working on something else (web interface), so it may take a while to implement this feature, perhaps a few months or so. I'll send you an e-mail through your SourceForge.net account as soon as it gets done, if it's okay with you.
In fact this web interface might even solve the problem. In one comment (in the web interface thread) you mention the possibility of running the server without the need of the desktop application.
In this scenario I could configure Launchy to use the web interface instead of the desktop application by passing the search term to the web interface (e.g. http://localhost:9091/docfetcher?search="search term")
The start parameters for the desktop application would be nice anyway. Some people might prefer having only one place for all their docfetcher needs. One reason I can think of is to have the indices updated before one searches for something.
What we had in mind was that when you enter http://localhost:9091 in the browser's address bar, you'll see a Google-like page where you can enter queries in a textbox and browse the results. A "?search" parameter in the address would have to be implemented separately, if I'm not mistaken. Is there an actual need for that?
Maybe there's are slight misunderstanding here? If the folder watching is on and if you let the DocFetcher daemon run in the background, the indexes are always up-to-date, whether DocFether is running or not.
I'd definitely say that there's a need for a search parameter. What makes Google's search so useful is that it is not the only place from where you can start to search. Just like Wikipedia or Google Docfetcher's web interface would fit perfectly in Firefox' search bar.
Btw search terms have to be sent from the client (i.e. the browser) to the docfetcher-server anyway (be it synchronous or asynchronous). So it can't be to much work to implement a hook to accept that search term from any source (firefox' search bar is just like any input field on any google-like web interface!).
How do you plan to pass the search term from the web interface to net.sourceforge.docfetcher.DocFetcher.doSearch(String) anyway?
The interface would look something like this:
<form action="http://localhost:9091" method="get"> <label>Search term:</label> <input type="text" name="search" value=""> <input type="submit" name="submit" value="Start search"> </form>What the server gets when you hit the search-button looks like this:
http://localhost:9091?search="search term"&submit=true
If you get the search results asynchronously things get a bit more complicated but somehow the search term has to reach the server. That's where anyone can start sending a search term to the server.
Hehe, you know more about web interfaces than I do ;-)
I'm mainly responsible for the desktop interface and project administration, and derkalender (real name Andreas) will deal with the web interface. He knows all the details.
If there's anything else you want to say about the web interface (design problems, additional wishes, etc.), feel free to post it on the other thread, we'd appreciate it.
... and the ?search parameter in the address is a good idea, of course.
This is a great feature and ought to have it's Priority increased.
Imagine, sitting at a cygwin prompt in windows. Hands on the keyboard.
docfetcher --search "filename:report kvm AND performance" | grep .txt | vi -
=> vi open to a list of files and their meta data
Stupid example but bringing unix methodology into the docfetcher world.
also how about:
docfetcher --search "kvm AND performance" --contents | vi -
and how about:
docfetcher --search "kvm AND performance" --contents -B 10 -A 10| vi -
=> this would dump the 10 lines before and after the words kvm AND performance in any file in my index.
(could also be done with docfetcher --search "kvm AND performance" --filenameonly | xargs egrep -B 10 -A 10 "kvm|performance")
Just some ideas...
@ Bill
I understand how this feature would be useful. The main problem though is that currently I have very little time to work on anything DocFetcher-related...
I have the same demand, so I made some modification on the current master branch to implement it.
Basically, I integrate py4j in docfetcher to provide python access to component in JVM, then it's easy to create a command line interface with python.
This can be used as a workaround before the command line interface is available in docfetcher.
Details can be found here.
Last edit: Zhengmian Hu 2018-05-05
@ Zhengmian Hu: Thumbs up for your hard work! :-D
This would be a really useful feature. Has this already been implemented or will it be implemented soon?
@peanuts: DocFetcher is no longer being developed. Only bugfixes and very minor improvements are planned for its future. Maybe this feature will be implemented in the commercial DocFetcher Pro, but there are no definite plans yet.