Done Allow FSEARCH to Search Pseudofiles

[Jay Sage]

I would like to request that the ability be added to the FSEARCH command to work with the pseudofiles TMP#: and CLIP#:.

I was writing code to see if folder monitoring was in effect for a specific directory. I tried redirecting the output of FOLDERMONITOR to TMP1: and then searching it for the folder path.

foldermonitor > tmp1:
fsearch /q /t"folder" tmp1:
if %_fsearch_matches GT 0 ...

When that didn't work, I discovered that FSEARCH doesn't work with the pseudofiles (and it gave no error message). Instead, I had to revert to the messy old method of redirecting to a temporary file.

It also appears that one cannot pipe into FSEARCH, so the following also did not work (with or without "con:" as the file). That feature, too, should be added to FSEARCH.

foldermonitor | fsearch /q /t"folder"

Ironically, the "obsolete" FFIND does accept redirected input! So I can use the following code:

foldermonitor |! ffind /q /t"folder"
if %_ffind_matches GT 0 ...

 

[rconn]

FSEARCH in v34 supports piping. (Actually FFIND does not support pipes; it writes STDIN to a file and then searches the file. That's very, very old DOS code.)

FSEARCH supporting the CLIP and TMP pseudodevices is a lot more complex, as they aren't either pipes or files, they're memory blocks. And memory blocks that are apt to be changed at any time by other threads / processes.

 

[Jay Sage]

Piping should take care of things. In addition, one can always do

type tmp#: | fsearch ...

You do allow many other functions (e.g., @line and %@lines, and commands, e.g., type) to work with the pseudodevices. The way I use the pseudodevices, I would not have to worry about some other thread or process messing with them while I was passing them to those functions or commands, or to FSEARCH. Perhaps it would cause problems for others, though one could argue that they shouldn't do that if it causes problems, but I know it's a nuisance for you when things seem not to work (I've been guilty of that!).