File not found after shell

[Cliff Nichols]

I have not done enough research (Yet that is) but MCM gave a heck of a clue

Or, maybe the PB/Windows "DIR" or it's API big brother "FindFirstFile()" will actually handle the multiple wildcards in your spec. (I would have to try that).

I used this idea with my Super Fast file find. (which I found in the last month or 2 when I needed it, but can not find searching on myself in the source code forum, so I wonder if time to resubmitt it when I can find it locally?)

FindFirstFile, FindNextFile tends to be WAYYYYY faster (especially if you thread the drives), but that is just from someone that barely touched the capabilities.

[Michael Mattias]

Now that you've described your application, I'll bet you get lots of ideas.

One I can think of off the top of my head is: Find a friend with Pb/CC or PB/WINdows. Have them write a little application which uses the PB DIR$ function to scan your filespec and build you a little disk file containing all the "hits"

In your example..

a$="cmd /c dir c:\pb35\*powerbasic*.txt" > Result.txt

The Windows code could accept a command-line of

CCPROG.EXE  c:\pb35\*PowerBASIC*.txt  result.txt

The CC program could run a DIR$ loop Against "C:\PB35" and use either regular expressions or the "ISLIKE" function which is posted here somewhere, and store "hits" in result.txt

Or, maybe the PB/Windows "DIR" or it's API big brother "FindFirstFile()" will actually handle the multiple wildcards in your spec. (I would have to try that).

That's One (idea).

MCM

[Alan Hanson]

I've been away for a few days so I haven't been back to post more info. The search that I'm running is testing for a few thousand word combinations for the names of a few thousand files. The method I came up with does a dir *power*basic* search and checks the screen using the screen command to test for a "file not found". This is a fairly fast test and doesn't thrash the disk as much as creating a file, checking the contents of a file then deleting it. The biggest problem is that it makes a horrendous mess of the screen and the other info being printed to the screen gets totally removed. If there was a powerbasic dir or a lfn equivalent that let you search for a *power* I could get my app sorted so that there is probably less than 10% of the hdd usage that I'm currently using. It would also mean the search is done approximately 10 times faster (a few minutes rather than the best part of an hour).

[Scott Slater]

Alan,

If that's the case you should maybe use the "Bare" switch with command line DIR. It would look like this.

Shell "DIR " + MySpec$ + /B " > D.TXT" ' Note the /B Switch
Open "D.TXT" FOR INPUT AS 1

Read each line of this file. *Note: In a "File Not Found" situation, you should get a single line of text that reads "File Not Found" on most OS's some may return an empty string.

So...

IF INSTR(UCASE$(ReadLine$), "NOT FOUND")) THEN ? "No File Found!"

[Alan Hanson]

The main reason that I'm using a shell rather than the native DIR$ or the lfn equivalent is that the DIR command that ships with windows XP and is accessed using cmd allows for multiple wildcards. Searching using the old DOS dir or the powerbasic DIR$ only allows for a suffix wildcard. Searching with *powerbasic*.txt will return every .txt match as it sees the leading wildcard and thats what it searches with. With the later DIR I can search *powerbasic*.txt or *power*basic*.txt and still get the results that I am expecting. The only problem is that I can't work out how to retrieve the file not found error.
If I can solve this problem it takes a lot of processing out of the program I'm using and it stops a lot of hard drive thrashing.

[Scott Slater]

This might help too:

http://www.powerbasic.com/support/pb...ead.php?t=1334

[Michael Mattias]

>Better yet would be to use the built-in DIR$ function rather

Um, I don't believe PB/DOS supports long file names in its DIR command.

But as Mr. Slater points out... to do 'anything' with this output using PB/DOS you will have to redirect the output of DIR and then 'do something' with it. Redirecting to a file, then opening, reading and parsing the file contents will be the most straightforward.


MCM

[Scott Slater]

You would have to redirect the output of the DIR command to a file eg.

a$="cmd /c dir c:\pb35\*powerbasic*.txt > result.txt"
shell a$
open "result.txt"...

Better yet would be to use the built-in DIR$ function rather than shelling to DOS. There is also a function that ships with PB-DOS in the Examples folder in the file DOSUNIT.BAS called "Exist" that will test whether or not a file exists.

The latter two methods are more correct than shelling out to the OS.

[Alan Hanson]

Hi. I'm trying to test for the existence of a file in a directory that meets the criteria of *powerbasic*.txt for instance.
If I do

a$="cmd /c dir c:\pb35\*powerbasic*.txt"
shell a$

(note the *powerbasic*.txt actually gets made up with chr characters as there may be spaces in the search"

then command will check for the presence of this lfn format file search and it also allows for the leading wildcard.

What I can't work out is how to retrieve the "file not found" error as a 1 or 0.

Thanks in advance if someone can help.