Audacity Forum

Split from http://forum.audacityteam.org/viewtopic ... 36#p310536

Here's a Windows .bat script to search a local copy of the Audacity manual for a given word or
phrase. It doesn't make inferences nor support wildcards as Google does, nor does it support regular expression searches. It could be modified to do regular expression searches, and wildcards would then be supported too although the syntax might not be as simple as with Google.

The results are displayed as a file list, which is essentially a subject list so that alone gives a context for the keyword/phrase match. Files can then be selected for display on the default browser. I don't know how to open multiple tabs simultaneously, but if additional files are selected once the browser is open it may add tabs rather than open new windows. It works this way with Mozilla and Chrome, the only browsers I've tested with it so far.

Installation consists of editing the file to insert the pathname of your help folder, removing the '.txt' extension from the file name, and saving the .bat file to the Desktop (or elsewhere with a shortcut on the desktop).

Happy Hunting

- DickN

Just a heads-up, there's a sequel coming for AudManSearch.bat. I eliminated the temp file and made a few other changes. I'll post it as soon as I fix a bug.

Here's the sequel, rev 1.1 of AudManSearch.bat. It eliminates the temp file and adds Rotating Selection and New Search. I wanted to add multiple keyword searches (AND rule), but there's something I need to learn first about how to get nested 'for's to work in Windows batch script. Maybe I should read a primer on Java instead - this is pretty basic.

Thanks, Dick.

Of course if the user runs the script from other than the C:\ drive, it only searches the current directory.

I don't know what to do about that unless you specify C through Z.


Gale

Interesting. I tried running it from a thumb drive and, as you said, it didn't find files in the man directory. Oddly, it didn't get an error (which would have triggered the reminder to insert the pathname of the help folder) when it changed directory to \manual\man in that path (which includes the drive letter).

If you're running from a command line and type 'j:audmansearch', it works (j: is my thumb drive). I remember now from the DOS days, CD <drive>:\<path> changes the working directory only for explicit references to that drive. OK, the fix is obvious.

Henceforth I'll include running from a thumb drive in my testing, which will also expedite testing on 3 different systems. I doubt this would be an issue for most users (especially if they launch it from an icon on the desktop), so will save the fix for next rev which one way or another will include multi-keyword search.

Thanks for the bug report!

Here's rev 2.0. It supports multiple keyword/phrase searches, returning files that contain all of them.
The drive:path bug is fixed, and IMO the script has a tidier interaction with the user.

Note that in rev 1, 'Q' just meant quit the display list and then start a new search if you want to, in rev 2
'Q' means quit and 'N' means start a new search.

There are some options for getting the path info:

Hard-coding (default option) is still in there and it works from any drive:path.
If the environment variable AudacityHelp is pre-initialized, it uses this with no editing required.

The other 2 options require removing 'rem 's from the file:

Option 2:
If run from a shortcut, the drive:path can be put in the "start in" parameter in the shortcut.

Option 3:
If the .bat file is saved in the Audacity folder, it finds the help folder relative to itself.
I like this version but I didn't make it the default because it's inflexible about where to put the .bat file.

I have a "3quel" (rev 3.0).

It does inverse searches (Any files containing a negated term are excluded from the results, rather like a real search engine but without the spelling checker.). It also gives a count of the matches, just in case you were wondering how long that list is.

The path setting is somewhat automated. The .bat script checks for a pre-set environment variable first, then the "start in" path given in the shortcut, then the .bat file's own folder, for the help folder. The actual path used is shown at startup. The only case where any editing of the .bat file is needed is if user wants to hard-code the path, which then overrides the above.

- DickN

I don't use Windows, but there are several search applications available for all platforms. One that I tried recently is a Java application that works on Windows, OS X and Linux (requires JAVA to be installed), called Puggle. It's a bit old (2010), but I found that it works very well and when set up to search only the manual, it is very fast.

Reminds me of my aside at the end of my Aug 6 post out of frustration with cmd.exe - "maybe I should read a primer on java instead - this is pretty basic".

I should look into getting an IDE for batch files - I wonder if they really reflect the actual behavior of a batch program running without the IDE.

My next iteration was going to be a specialized version simply because I have use for a similar search on label tracks among an archive of Audacity projects. Think I'll save myself some work and try Puggle for that. I don't really want to index everything though - I assume that means creating a database of keyword occurrences so the files don't have to be re-scanned for each search. That would be wasteful in a library that doesn't get searched very often, especially when only a small part of each .aup file is pertinent to the searches. Can Puggle target particular tagged blocks in .xml files?

Puggle creates a database on first use. From first launch of Puggle, setting the search directory, waiting for it to create the database, to getting my first search result, took perhaps 30 seconds. After that, search results are virtually instant. It has "extractors" for "documents", "music" and "pictures". I'm not sure what format documents it supports, but it has no problem with html. which is what we need for the manual. I think the "music" and "pictures" searches extract metadata from common audio / image formats. There's even built-in help, but I've not used that. The other nice "feature" is that it runs without elevated privileges (just ordinary user account).

For searching data that hardly ever changes, a database is the way to go. It scans the files once, then you get very fast searches whenever you need them. The database would only need to be rebuilt when you update the manual, and that only takes about 10 seconds on my old budget laptop for the entire manual.

Other than that, all I know about Puggle is what is written on its website http://puggle.sourceforge.net/

There are also a number of open source desktop search apps written in Python, and I found this article which may be of interest, about writing your own search engine using Python, HTML and JavaScript http://www.zackgrossbart.com/hackito/se ... ne-python/

Obvious advantages of JAVA or Python is cross-platform support.
Advantages of making a custom search engine for the manual is that it could be optimised for how the manual is written, giving different weightings for when a search term is found in a header, anchor, file name .... as well as the total number of occurrences in the file.