Welcome to the Mythicsoft Q&A site for:

- Agent Ransack
- FileLocator Lite
- FileLocator Pro

Please feel free to ask any questions on these products or even answer other community member questions.

Useful Links:

- Contact Us
- Help Manuals
- Mythicsoft Home
0 votes

when using DOS expressions (not the perl type)

If I type xyz123 into the search file name field, then according to the rules of DOS, I SHOULD get only the exact file name match.

Instead I get anything that has xyz123 anywhere in the file name string.

I find no "exact match" option under, well, options.

I finally stumbled across an unexplained comment (in a blog entry by a Mythicsoft customer service employee) about using something like bterm/b (see, I've already forgotten it, plus it wasn't explained in that blog entry WHERE to enter the limiting term)

Is there a way to force the default to be "exact match"? If I want the current default behavior I am more than capable of using the appropriate wildcards. But I can't find an easy way to force Ransack to find only the exact match THAT I CAN REMEMBER. I need a "set it and forget it" method if at all possible. Command line settings, or an ini type file - anything like that.

asked by (30 points)

1 Answer

0 votes

It's an interesting problem since we also have support requests along the lines of "I'm searching for 'xyz' but nothing comes up and I know that there's a file called 'xyz123' in the folder".

If no extension is specified in the file name, e.g. xyz123.txt, then Agent Ransack will effectively search for

*xyz123*

At the moment the only way to search as you want is with Regular Expressions, something like:

^xyz123$

The ^ matches the start of the file name and the $ matches the end.

FileLocator Pro has an easier syntax to remember with DOS expressions. You can specify the boundary with:

<xyz123>
answered by (67.2k points)

There's nothing "interesting" about it. That's just silly. The correct way to get any string with xyz123 anywhere in it is to use the wildcards. So you've killed off the possibility of getting an exact match (easily, at any rate) in favor of not letting people use the well established wildcards in a properly formulated search? That makes no sense at all.

If you want to find everything with xyz123 in it it's simple - just enter [star]xyz123[star]. It's not hard to tell people that, it's already documented in thousands of places and has been around for over 30 years. You have to use wildcards anyway if you don't want a totally crippled search utility, so using them to get [star]xyz123[star] isn't any greater learning burden than understanding that you use them to get, say, all .bat files by entering [star].bat.

Had to change the wildcard symbol from an asterisk to [star] because your editor apparently uses the asterisk to delimit italics - which is also weird. I can't say as I've ever seen that before.

So basically you are NOT using DOS expressions. So please stop telling people that you are (when not using "regular" perl expressions).

FileLocator Pro is ALSO not using DOS expressions if you have to delimit a string in anyway in order to get an exact match.

Regardless, I am apparently misapprehending your statement:

"If no extension is specified in the file name, e.g. xyz123.txt, then Agent Ransack will effectively search for xyz123."

This is not the behavior I am seeing so I presume that this isn't actually what you mean. Because the behavior I am seeing is NOT that searching for xyz123 (with no extension) returns xyz123 in a search, but in fact it returns ANYTHING that contains xyz123 anywhere in the file name, including:

asdlkf000xyz123aaa03848.xxx

xyz123

000xyz123aaa

filename.xyz123

So what Agent Ransack is EFFECTIVELY searching for is [star]xyz123[star]

This is a weird drawback to both versions that I simply do not understand, but I'll bet it's well-established in this product line now, so I figure the chances of getting searches implemented correctly is 0%.

It does mean that there is now absolutely 0% chance of me "upgrading" to the Pro, since it won't give me an exact match either via normal file search protocol, nor will I recommend it to anyone else.

You COULD fix this - just give us a switch at runtime to enforce true DOS expressions or not. Default would have to be not using true DOS expressions, since that's what you've trained your customer base to expect at this point, but setting a flag at runtime would at least allow folks to easily get an exact match the normal way, while not removing any capability at all. All DOS file search syntax would still work as-is, with the exception that now wildcard presence or absence would be interpreted correctly.

Imagine a situation where a user has named their file 'My Trip To London.doc' and they search for simply 'Trip'. 9/10 people would expect the file to show up. Windows over the years has not been consistent with how it handles this case and so it's hard to provide a definitive implementation.

However, the next version of FileLocator Pro will support the stricter interpretation of DOS Expression with its Strict DOS option.

...