Thank you for comments, especially for idea of bin files. So what's in your opinion is the right place in mono tree for such tool?
This is a clever idea. Just a few suggestions:
1) try testing for binary files when you open something to see if it has
any path references in it. For our purposes, "binary file" can be
defined as any file which contains a \0 in it's first 8 kb of data. The
chance of a randomly generated file failing this test is
(255/256)^(8*1024), or 1.2 × 10^-14. This should prevent any need for
"tuning".
----
wow, that's really good idea.
----
2) would need a manpage, etc to show how to use it.
----
I will start with a simple README
----
3) Why not have a mode where it does the find -type f for you, and then
looks at all the files. This will be practical once you do 1 to remove
binary files from consideration.
----
I started with the find phase included, but then I saw that I want a manual intervention. As I said, plain find produces some noise. And in such projects I usually run few finds and create indeces to search for files faster. As these indeces include many files from the actual tree, they slow down the process alot. Especially with the naive search algorithm I used. But now I have a better algorithm in mind, stay tuned ;-)
----
4) IMHO, we shouldn't only look at files, directories might be
referenced too.
----
Again, I started with directories included, but then many directories like ./Something/Xml produced noise on every string like <?xml version="3.0"?>. Files are better, because they usually have extensions. And if you control the find phase, nobody prevents you from running find without -type f.
----
5) Any ideas on how to catch not using path.combine?
----
not yet :-(
----
-- Ben
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
