Might be useful.
(Ability might already be there?)
As it is, -search-file-list "typically" (I'd think) deals with (works around) the concept of wfn: (or ww:).
So you have a list of 'file names'
Code: Select all
abc123
red.txt
blue.txt
So "abc123" is found, but not "abc1234".
If your list had "abc123*", then in that case both "abc123" & "abc1234" would be found, but I'd think not to by "typical" (for your list to have something like that).
So if there existed -searchstringlistAND, -searchstringlistOR
where AND returns results in an AND fashion
& where OR returns results in an OR fashion
you could search a 'list' that was essentially an extension of -s <text> does, only from a file list.
In one variant (AND), you get:
abc123 red.txt blue.txt
And in the other (OR), you get:
abc123 | red.txt | blue.txt
And again, these are "simple" <text> searches, so abc123 also finds abc1234 (&4321abc1234).
Likewise, you could use \ in your list, such that "\abc123" would only find "abc123" at the beginning of a path (something that you cannot do with -search-file-list).
Similarly this a method to get around command-line or environmental variable limitations.
-searchTEXTlistAND, -searchTEXTlistOR