On Thursday 30 March 2006 11:49, you wrote: > How many keywords do we need to provide maximum flexibility on the > components of the URI? (I'm thinking we need five.) > > Consider http://www.example.com/path/to/script.cgi?foo=bar > > --filter=uri:regex could match against any part of the URI > --filter=domain:regex could match against www.example.com > --filter=path:regex could match against /path/to/script.cgi > --filter=file:regex could match against script.cgi > --filter=query:regex could match against foo=bar > > I think there are good arguments for and against matching against the file > name in "path:" > > Tony
The query keyword is a great idea. So many of the sites I download from use that, and would greatly help in limiting the material that is downloaded. I was also wondering this, does the "path:" need the begin and end slashes or are those assumed? They could be assumed, but if you combine the "file:" with the path I'm not sure you can make that assumption anymore. This comes into play when wanting to search from the start, or at the end of a path. --filter=path:^path/to/files or --filter=path:^/path/to/files --filter=path:path/to/files$ or --filter=path:path/to/files/$ Also any way to add modifiers to the regexs? The only modifier I can think of off the top of my head that would see much use is /i. I download material from a site where for some reason they use a KRS and a krs interchangeably in the path name. So something akin to: "--filter=path:^path/to/(?i:krs)" would be helpful. Or some other way to include modifiers? Curtis
