On Tue, 2003-10-21 at 23:11, rikona wrote: > Hello Jack, > > Tuesday, October 21, 2003, 4:14:37 PM, you wrote: > > >> Is there a way to get the output of swish-e to operate as an > >> 'integrated viewer'? > > JC> I don't know for sure, but I think that Nautilus or Konqueror would fit > JC> the bill there. Both have intense MIME capabilities. > > Interesting idea. Can either Nautilus or Konqueror be run in a > split-screen mode where one screen shows links to the files (produced > somehow from swish-e), and the other part displays the contents of the > file link selected?
I think so, but I'm out on a limb as I don't use Swish-e or either file manager on a regular basis :-) However, what I remember of Konq and Nautilus is that they display the first few lines of a text/word/excel/anything-parseable file in the thumbnail icon. I also deal with monster collections of files though, and what I do is keep a terminal open in the directory. If I need to find an example of how a particular function is used then, I type: grep -r . function-name | grep -v docs That second grep is because our documentation is in HTML, uses the function-name many times, and is frequently wrong, so including the docs just makes the matches I want scroll off the screen. I get back a list of filenames with relative paths and the matched line, so I look for one that looks likely, select it with the mouse, and: gvim [mouse middle-click] [enter] then /function-name[enter] If I was working with office documents, I'd be using oowriter [mouse middle-click] [enter] and Ctrl-F function-name, but same idea. If I just want to find a file by its name, I use locate, sometimes with the -e switch to limit to a specific directory. > > Some files are rather large (20+ megs). Is it possible to get the > display portion to automatically scroll to the search word(s), and > highlight each occurrence? It's VERY hard to find otherwise in a big > file. > > Also, are there MIME and/or plugins for Office docs so it would > display these as well? I've got perhaps 10,000 of these in the data > collection. > And PDF, and image files, and... their web page is good. I haven't actually needed a search engine yet, but I know that replacing ht::dig is on the to-do list at work, so when my current projects are done I might be taking a swing at it. > JC> that viewer sounds tough, but here's a two function CGI web search > JC> interface that uses MS-SQL as its backend: > > I'm afraid you lost me a bit here. It looks as though you are building > the search results to deliver to a web page. It is not clear how the > data base would be set up to show where in the document the search > words are, though. It would seem as though indexing each word in a > file would produce a gigantic data base. Am I missing something? > Kind of... I didn't give you the program that inserts data into the database because it's part of a ten-year old accumulation of home-grown ticket system cruft that no one fully understands :-) Something simpler would be, well, simpler to do but would require some knowledge about the goals at hand. Try freshmeat though, or read up on Perl::DBI at search.CPAN.org. MS-SQL then does a full-text index of the database table that's being searched every few hours. It actually isn't that large, comparatively -- not enough to notice. Whichever database you were back-ending with would need to have full-text indexing capability to make this fast, but if it doesn't the searches will still work, only slower. One other thing you missed is that the results page includes the matching line(s) from the record that matched, so that context can be checked by a human. > Thanks for the info, again. -- Jack Coates Monkeynoodle: A Scientific Venture...
Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
