Better, more simple searching

hydrurga · 02-20-2017, 04:41 PM

Quote:

Originally Posted by VolumetricSteve

Ugh! I lost my post! @szboardstretcher - I was thinking of doing something with 'cal' output and offering sort of a wizardy walkthrough type thing, but also offering the option to disable the walkthrough. I want the user input to be visually gentle, like (12-01-1997) (12-25-1997) where if the script sees two dates, it treats them as a range, but if you only give it one date it'll handle it as the only date to search on. I almost never search on dates, so while this is an important feature, I'll have to tinker with it to get it right. My big push is on allowing the script to be simple enough, and forthcoming enough, so the user never feels like they need to resort to a man page or google to figure out how to use it. I'm thinking 'scriptname' --help should provide some basic background, but other than that my goal is to make the various features so dead simple that you wouldn't need to 'read up' on much else, if anything.

Ah, the 12th of Podcember. Remember the internationalisation requirements (best to interpret dates according to the user's locale).

syg00 · 02-20-2017, 10:45 PM

Searching is incredibly inefficient. That's why indexers keep being foisted on us.
Remember the bad old days (before mlocate) when updatedb would flush the page-cache and drive everybody's I/O response time to hell ?. Used to be 02:00 was a good time to do it - but that was before a connected world became the norm.

The desktop indexers do similar - I have severely restricted "tracker" because of how much it interfered. And its predecessors/competitors aren't any better. At least tracker appears to have a CLI interface. Maybe check that out - might save you some coding (and angst).

Jjanel · 02-21-2017, 02:48 AM

I love 'CLI puzzles', and web-searches ('keywords' are similar to this concept)
I start with locate, and | egrep 'x|y|z' | egrep -v 'a|b|c' (manually 'crafted' 'on the fly')

I just tossed this web-search: locate find size file date executable package
which provided 'food for thought': 25/35 examples of find (find is too slow, but desired concepts)
One way of 'designing' this, might be to: collect a [long] list of 'desired search parameters'.

-I- would suggest adding the 'universe' of pkg/repo searching too! (yes, a major 'shift')
(I'm [currently] Newbie on this, so 'simplification' here would be welcome.)

Best wishes... looking forward to what you 'come up with'

p.s. a n/a WinGUI (tho sample of concepts)

VolumetricSteve · 02-22-2017, 08:17 AM

@hydrurga - considering the locale is a good idea, I'll look into that
@syg00 - I'm inclined to agree about the foisting. That's why my method will be to build a huge DB on demand, and you'll have the choice to save it or not. For my own use case, I'd rebuild roughly every other day, but it also takes me about 5 seconds. I'm thinking for people who maybe want to run this on big archive systems, or some other case where contents don't change much, they could retain the DB and avoid the need to rebuild at all.
@Jjanel - Thanks for the input, hopefully I can come up with something more concrete in the months to come.

hydrurga · 02-22-2017, 09:22 AM

Quote:

Originally Posted by VolumetricSteve

@hydrurga - considering the locale is a good idea, I'll look into that

On reflection, an easier solution might be to force date searches to use the yyyy-mm-dd format.