Announcement

Collapse
No announcement yet.

File not found after shell

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • File not found after shell

    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.

  • #2
    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.
    Scott Slater
    Summit Computer Networks, Inc.
    www.summitcn.com

    Comment


    • #3
      >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
      Michael Mattias
      Tal Systems (retired)
      Port Washington WI USA
      [email protected]
      http://www.talsystems.com

      Comment


      • #4
        This might help too:

        http://www.powerbasic.com/support/pb...ead.php?t=1334
        Last edited by Scott Slater; 2 Jul 2009, 09:35 AM.
        Scott Slater
        Summit Computer Networks, Inc.
        www.summitcn.com

        Comment


        • #5
          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.

          Comment


          • #6
            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!"
            Scott Slater
            Summit Computer Networks, Inc.
            www.summitcn.com

            Comment


            • #7
              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).

              Comment


              • #8
                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..
                Code:
                a$="cmd /c dir c:\pb35\*powerbasic*.txt" > Result.txt
                The Windows code could accept a command-line of
                Code:
                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
                Michael Mattias
                Tal Systems (retired)
                Port Washington WI USA
                [email protected]
                http://www.talsystems.com

                Comment


                • #9
                  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.

                  Engineer's Motto: If it aint broke take it apart and fix it

                  "If at 1st you don't succeed... call it version 1.0"

                  "Half of Programming is coding"....."The other 90% is DEBUGGING"

                  "Document my code????" .... "WHYYY??? do you think they call it CODE? "

                  Comment

                  Working...
                  X