Announcement

Collapse
No announcement yet.

Shell Function

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

  • Shell Function

    Please add your comments and suggestions as a Reply to this thread.





    PB/WIN - SHELL function

    Purpose
    Run an executable program asynchronously (as a separate process), while execution of the original application continues uninterrupted.
    Syntax
    [FONT='Courier New'][I]ProcessId??? i
    Remarks
    The SHELL function has the following parts:
    CmdString
    The name of the program to execute ("child process"), along with and any required arguments or command-line switches.
    WndStyle
    A number corresponding to the style of the window in which the child process is to be executed. If WndStyle is omitted, the program is opened normal with focus, the same as WndStyle = 1.

    The following table identifies the values for WndStyle and the resulting style of window:

    Code:
    +----------------------------------------+
    | WndStyle | Window style                |
    +----------------------------------------+
    | 0        | Hide window                 |
    +----------------------------------------+
    | 1        | Normal with focus (default) |
    +----------------------------------------+
    | 2        | Minimized with focus        |
    +----------------------------------------+
    | 3        | Maximized with focus        |
    +----------------------------------------+
    | 4        | Normal without focus        |
    +----------------------------------------+
    | 6        | Minimized without focus     |
    +----------------------------------------+
    SHELL returns the process id of the child process. The process id is a 32-bit LONG or DWORD value that identifies the child process, if it's a 32-bit or 64-bit process. If the process id is zero, the child process is not a 32-bit or 64-bit process, or an error occurred. Use ERR to detect the success of the SHELL function. The HANDLES option allows the child process to inherit the file handles opened by your program. This affects only Windows handles, not PowerBASIC file identifiers. It is an advanced option, for those who know it works and why they need it.
    Restrictions
    Child processes run asynchronously, or independently of the program that SHELLs. So, the child process is, probably, still running after control returns from SHELL to your program. Also, if your program ends before the child process, the child process will continue to run.

    To use internal DOS commands like DIR and COPY, you must run the DOS command processor, passing the DOS command as a parameter. See the example below.

    If the program name in CmdString does not include an explicit path, Windows will search for the file in the following paths: the directory where the current program is located, the default directory, the 32-bit Windows system directory, the 16-bit Windows system directory, the Windows directory, and any directories listed in the PATH environment variable.
    See AlsoExamples
    Code:
    pid??? = SHELL(MyApp$,1)
    pid??? = SHELL(ENVIRON$("COMSPEC") + " /C DIR *.* > filename.txt")
    Last edited by Gary Beene; 28 Oct 2014, 09:24 PM.

  • #2
    Distorted syntax, should be
    ProcessId??? = SHELL([HANDLES,] CmdString [, WndStyle])
    Rod
    "To every unsung hero in the universe
    To those who roam the skies and those who roam the earth
    To all good men of reason may they never thirst " - from "Heaven Help the Devil" by G. Lightfoot

    Comment


    • #3
      Something I noticed In PBWin7 (the same for all versions?):
      Unless the return value is assigned to a variable, it will be synchronous, the same as the Shell statement.

      Result = Shell("NotePad.exe") ' This will be assynchronous
      Shell("NotePad.exe") ' This will be synchronous
      TheirCorp's projects at SourceForge

      TheirCorp's website

      sigpic

      Comment


      • #4
        Tony Burcham - That is documented in the SHELL Statement vs. Function documentation..


        https://www.powerbasic.com/help/pbcc..._statement.htm SHELL statement

        Purpose Run an executable program synchronously. The SHELLing thread of the calling program is suspended until the SHELLed program ends.



        https://www.powerbasic.com/help/pbcc/shell_function.htm SHELL function

        Purpose Run an executable program asynchronously (as a separate process), while execution of the original application continues uninterrupted.
        <b>George W. Bleck</b>
        <img src='http://www.blecktech.com/myemail.gif'>

        Comment


        • #5
          "EXIT TO ..." is optional in SHELL statement. So the only way the compiler can tell the difference is by varname and "=" preceding the word SHELL for the function.

          ((in post 1 the syntax is still not showing))

          Cheers,
          Dale

          Comment


          • #6
            @George
            "That is documented in the SHELL Statement vs. Function documentation.."

            What wasn't clear to me was that one couldn't simply add the parentheses and omit the assignment
            to a variable for function-type operation. The difference between the requirements for calling a Function
            versus a Sub is usually nothing more than the parentheses --- assignments are never required.
            TheirCorp's projects at SourceForge

            TheirCorp's website

            sigpic

            Comment


            • #7
              Tony, the presence of parentheses is not distinctive either. A SUB may have them; and at times must have them, depending on presence of parentheses in the passed parameters.

              Is it really that hard to put a dummy variable to let main process to continue while SHELL completes?

              Cheers,
              Last edited by Dale Yarker; 7 Sep 2016, 08:58 PM.
              Dale

              Comment


              • #8
                @Dale Yarker
                At the time I didn't need the return value, so I planned to ignore it by not cluttering up the code with an extra
                variable to assign it to. It wasn't any big deal, it's just that I didn't immediately realize what it took to tell the
                compiler that I wanted the function instead of the statement form. With my mistaken assumption, I tried it
                several times and wondered why it was still synchronous.
                Often variables are added as examples of normal usage, so the presence of the variable in the function's
                definition didn't strike me as implying it was actually necessary. It would be a simple matter for the manual
                to clarify just what is essential to get the intended results.
                TheirCorp's projects at SourceForge

                TheirCorp's website

                sigpic

                Comment


                • #9
                  It would be a simple matter for the manual
                  to clarify just what is essential to get the intended results.
                  It does.
                  From Help for SHELL Function
                  Syntax ProcessId??? = SHELL([HANDLES,] CmdString [, WndStyle])
                  From Help for SHELL Statement
                  Syntax SHELL [HANDLES,] CmdString [, WndStyle, EXIT TO exitcode&]
                  ((I mean the real PB Help installed on your computer with compiler and IDE))

                  If Help needs fixing it is for CALL. It states there the rules for parentheses for procedures (SUBs and FUNCTIONs); implying they are the same. But you are correct, the rule is different between SUB and FUNCTION. (I tested before making my previous reply. (Which is also correct about lack of distinctiveness.))
                  Dale

                  Comment


                  • #10
                    I think what must have happened here is that no one has noticed they are in the PB/Win Online Help & Commentary sub forum rather than the more popular sub forums where people describe programming difficulties and hope for solutions. I posted about this issue in case it might help others.
                    I did not post this about an existing problem. I solved the problem that I had. A function which invokes other programs needs to be described more thoroughly than others because of the more numerous potential misinterpretaions of failures. For any failure of Shell, one has to potentially consider whether it's due to:
                    • A bad path
                    • A missing file
                    • Missing double-quotes
                    • Bad commandline parameters
                    • Bad commandline arguments
                    • Inadequate permissions
                    • Windows having internal problems

                    ...but one should not have to wonder whether he's used Shell as a statement or a function.
                    I've read the syntax definitions for Shell, but it does not indicate just how much of the differences are actually decisive in determining what Shell does. No function I've ever encountered anywhere did anything differently based on whether or not the return value was saved or ignored, and since I hadn't, I assumed that PowerBASIC staff never had either. So, since such a dependency is rare, if not unique, and therefore unexpected, I assumed that it would have been mentioned in the manual, especially since it makes an important difference in what Shell does. If, after all my years of programming, any documentation isn't clear enough for me, then it probably isn't clear as clear as it should be.
                    What was intended as a suggestion for a short line to add to the manual has turned into a way-too-long discussion. I'm through with this thread now.
                    TheirCorp's projects at SourceForge

                    TheirCorp's website

                    sigpic

                    Comment


                    • #11
                      A function which invokes other programs needs to be described more thoroughly than others because of the more numerous potential misinterpretaions of failures. For any failure of Shell, one has to potentially consider whether it's due to:..
                      That is neither practical nor possible.The SHELL statement or function merely launches and reports "successfully launched" or "not successfully launched." When used in function form some very minimal extended information is available for "not launched" via the system ERR variable.

                      All the failures you list are failures of the launched program, except for the "bad path/missing file" which may mean the launched program was not found - launch unsuccessful - or the launched program could not locate a file name named as an argument on the command line. To allow SHELL to report an application failure - which occurs only once the program has been successfully launched - would require a knowledge of every possible return code from every possible launched program.

                      Unless maybe this is the 'short line' of additional text you wanted to add to the help file?



                      .

                      Comment

                      Working...
                      X