Declined Add optional parameters to @search

[rps]

Add optional parameters to @search to include sub-directories with the supplied path such as @search[program[,path[,n][,s]]]. Example: %@search[mytest.lst,"c:\jpsoft\",,s] would search in C:\jpsoft and all of it's sub-directories. It would also be useful to be able to supply multiple search directories, such as %@search[mytest.lst,"c:\jpsoft\;d:\my specdir\".

Failing this, suggest the current @search docs be revised to show that searches are not recursive. The second example sure does indicate this.

 

[Charles Dye]

I think this misses the purpose of @SEARCH. It's there to perform a path search for executables, like TCC does when you type something at the command line. A function to recursively search arbitrary path(s) for a file should be a different function altogether, say @FFIND.

 

[rps]

I think this misses the purpose of @SEARCH. It's there to perform a path search for executables, like TCC does when you type something at the command line. A function to recursively search arbitrary path(s) for a file should be a different function altogether, say @FFIND.

Quite aware of the current limitations.

I don't use it to search arbitrary paths. But the default is to search the entire current path, which is rather long and represented by a semi-colon list of many directories that do not need to be searched. I just thought that providing a means for the user to search a shorter, user defined "path" would be quicker and more efficient.

My example of searching c:\jpsoft\ and it's sub-directories has become more relevant recently, due to the need to subdivide all the files, which include batch files, into sub-directories to better organize things. Not sure how I see the undocumented function "@ffind" as the go-to function replacing @search. BTW where is @ffind[] help located? Couldn't find it in the off or on line documentation. Probably why I've never used it.

Perhaps a doc page with a few practical examples would be persuasive. I will admit that I have used @search more often than ffind (read almost never) and will do more research to see if I am able to locate what I need with @ffind recursion when I find the docs. I very rarely use plug-ins, just in case this @ffind[] function isn't currently native to tcc.

In any case, the current @search help needs revision as above and adding a better purpose statement. i've been using it the way I think it should be, but I may have missed the point.

Thanks for stimulating some discussion. I was beginning to think everyone was ignoring the suggestions forum. Sometimes there is better information here when users discuss the pros and cons of a suggestion. TTL

 

[Charles Dye]

BTW where is @ffind[] help located? Couldn't find it in the off or on line documentation. Probably why I've never used it.

Sorry, I wan't clear there. There is no @FFIND function. That was just a suggested name for a hypothetical new function, intended to reflect what the function would do -- search subdirectories like the FFIND command does.

 

[rps]

Now I'm with you. I will add that to this forums suggestions with a more appropriate Subject.

I also discovered that I can add a string of folders to the @search[] functions. I just had to be more careful about where I placed my double quotes.