Announcement

Collapse

New Sub-Forum

In an effort to help make sure there are appropriate categories for topics of discussion that are happening, there is now a sub-forum for databases and database programming under Special Interest groups. Please direct questions, etc., about this topic to that sub-forum moving forward. Thank you.
See more
See less

Run or execute a program with a switch

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

  • Run or execute a program with a switch

    When you run a program from the DOS prompt, you
    can specify a parameter or "switch" along with it:
    prog/s or prog s
    The switch is accessible in the program by the
    PB function COMMAND$.

    I want to run a program starting from within a
    program, using either the RUN or EXECUTE command.
    Is it possible to specify a parameter along with
    the program? This works:

    RUN "prog.exe"

    but these don't:

    RUN "prog.exe s" ---> error 53 file not found
    RUN "prog.exe/s" ---> error 76 path not found
    (though / not \)

    (I want to avoid, if possible, the program writing a
    little file before RUN and prog reading it to get s.)

    Politically incorrect signatures about immigration patriots are forbidden. Googling “immigration patriots” is forbidden. Thinking about Googling ... well, don’t even think about it.

  • #2
    As I understand it (and I'm sure the PB folks will chime in if I'm wrong ), RUN and EXECUTE do not invoke a copy of COMMAND.COM the way SHELL does - rather, they pass the parameter you give them directly to the DOS service for loading and executing a program. (Which, among other things, is why the original program doesn't get control back when the second program finishes.) Unfortunately, COMMAND.COM is what "parses" the command line, and sends the program name and parameters to the appropriate places; without it, the "exec program" DOS service is being handed what it thinks is a request to run a program named, literally, "prog.exe s".

    There are two ways you might be able to work around this, and pass parameters to the second program without an intermediate file. One way is to have your first program stuff the keyboard buffer, then have the second program pick up its instructions via the INKEY$ statement; the other is to declare some variables as COMMON in both programs, then use CHAIN to transfer control from one to the other.

    ------------------

    Comment


    • #3
      Gary Akins --

      Good idea stuffing the keyboard buffer.

      Another way to pass a parameter to another program
      is to use the inter-application communication area:

      'In "calling" program
      Code:
       DEF SEG = &h4F0     'segment of i.a.c.a.
       POKEI(0),%code
       RUN "prog.exe"

      'In "called" program (prog)
      Code:
       DEF SEG = &h4F0	   'segment of i.a.c.a.
       IF PEEKI(0)=%code THEN ...
      which is sort of the same idea.



      [This message has been edited by Mark Hunter (edited March 21, 2001).]
      Politically incorrect signatures about immigration patriots are forbidden. Googling “immigration patriots” is forbidden. Thinking about Googling ... well, don’t even think about it.

      Comment


      • #4
        Also have a look at the "pbvUserArea" internal variable. Although
        it's limited to 32 characters, I think it was meant for these
        situations...

        ------------------
        Sebastian Groeneveld
        mailto:[email protected][email protected]</A>
        Sebastian Groeneveld
        mailto:[email protected][email protected]</A>

        Comment


        • #5
          I use parameters with the execute statement all the time. The
          following works for me:

          runjob$ = "d2twc "+tapedrive$+" "+arg$(2)+" 1" 'arg$(2) is the output file name
          execute runjob$




          ------------------

          Comment


          • #6
            Aaagh... that'll teach me to try it for myself before I open my big mouth, I guess...

            I just tested it with a couple of files, and Martin is correct:
            Code:
            EXECUTE "pkunzip -v D:\host.zip"
            works as intended.
            Code:
            RUN "pkunzip -v D:\host.zip"
            , however, does not work.

            Presumably, then, RUN invokes the "load program" DOS service directly, while EXECUTE does go through the command-line parsing routines in COMMAND.COM. Perhaps someone from PB can explain what reason there would be to prefer one over the other?


            In any case, here's the keyboard-stuffing code if anyone's still interested... (this has been tested, BTW, and found to work on both plain DOS, and in DOS sessions under Win9x. Note, however, that it does not work correctly from within the PB/DOS IDE - I have, in fact, managed to confuse PB/DOS with it to the point where the IDE quits responding to the keyboard at all, so use with caution.)

            Code:
            DECLARE SUB KBStuff(STRING)
            
            SUB KBStuff (Cmd$) STATIC PUBLIC
              LOCAL Head%, Tail%    '--head and tail pointers for keyboard buffer
              LOCAL Start&          '--keyboard buffer's starting position in memory
              LOCAL Work$, Length%  '--working (truncated) copy of Cmd$, and its length
              LOCAL PBDataSeg??     '--PowerBASIC data-segment preservation
            
            '-- Limit the string to 14 characters plus <CR>
              Work$ = LEFT$(Cmd$, 14) + CHR$(13)
              Length% = LEN(Work$)
            
            '-- Set the segment for poking, define the buffer head and tail,
            '   and then poke each character.
              PBDataSeg?? = pbvDefSeg
            
              DEF SEG = &H40          '--Switch to BIOS data segment
              Head% = &H1A            '--Buffer head pointer
              Tail% = &H1C            '--Buffer tail pointer
              Start& = PEEKI(&H80)  '--Pointer to keyboard buffer
            
            '-- mow stuff the buffer
              FOR X = 1 TO LEN(Work$)
                POKE Start& + (X - 1) * 2, ASC(Work$, X)
              NEXT
            
              POKE Head%, Start&                  '--Set new head pointer
              POKE Tail%, Start& + (X - 1) * 2    '--Set new tail pointer
            
              DEF SEG = PBDataSeg?? '--return to the PowerBASIC default data segment
            END SUB
            ------------------


            [This message has been edited by Gary Akins (edited March 21, 2001).]

            Comment


            • #7
              If you check the help file you will find that run only works with
              programs compiled with pb.
              Keith Shelton

              ------------------

              Comment


              • #8
                Stuffing the keyboard doesn't work if going to
                some programs. Found out the hard way.
                I use error levels in a running batch file to
                control jumping between programs. It also
                has the advantage of clearing all memory and
                making sure Windows never gets control.
                Something like this:

                Start.Bat
                :top
                If errorlevel 5 if not errorlevel6 goto 5
                if errorlevel 4 if not errorlevel5 goto 4
                goto end
                :5
                goto top
                :4
                goto top
                :end



                ------------------
                How long is an idea? Write it down.

                Comment


                • #9
                  Gary --

                  To go off on a tangent, about the keyboard
                  stuffer. The following works for me within
                  a program (not EXECUTE-ing to another).

                  Code:
                  sub KBstuff(a$)
                   dim i as integer
                   for i=1 to len(a$)
                    reg 1,&h0500             'ah=5  KB services, al= n/a
                    reg 3,asc(mid$(a$,i,1))  'cx=ascii (scan not needed if ascii)
                    call interrupt &h16
                   next
                  end sub
                  About run/execute/chain. Run or Execute is preferable
                  to chain if you are interested in keeping the executable
                  small -- though you must do extra work to preserve what
                  variables you want. Chain adds about 32K to the exe file
                  compared with the other two.

                  Sebastian Groeneveld --

                  Yes, pbvUserArea works with run and chain. It doesn't seem
                  to work with execute. The BIOS inter-application communication
                  area works with execute as well -- as long as you stay in that
                  session of DOS and don't jump back to Windows (if Windows is
                  running).


                  [This message has been edited by Mark Hunter (edited March 21, 2001).]
                  Politically incorrect signatures about immigration patriots are forbidden. Googling “immigration patriots” is forbidden. Thinking about Googling ... well, don’t even think about it.

                  Comment


                  • #10
                    Er.. why would you want to stuff the keyboard from within your own program, though? (Not arguing, just curious; it's not something I've ever had reason to do...)

                    Actually, my question was more "Is there any reason to prefer RUN over EXECUTE", i.e. does RUN fulfill a purpose (other than backwards-compatibility with old code) that EXECUTE doesn't, that would make it the more appropriate or advantageous command to use in some situations?

                    ------------------

                    Comment


                    • #11
                      Gary --

                      Sometimes I stuff the KB buffer in a subroutine to
                      access a program's menu routine in the main part of
                      the program. Thus a nether part of the program
                      can comunicate with the menu without using flags.

                      Setting the character variable and going to what
                      follows the get key routine would require some sort
                      of flag or extra code.

                      About my original problem: I ended up using
                      execute and the the inter-application communication
                      area. It works fine.
                      Politically incorrect signatures about immigration patriots are forbidden. Googling “immigration patriots” is forbidden. Thinking about Googling ... well, don’t even think about it.

                      Comment

                      Working...
                      X