I'm having a problem with SHELL

[James McNab]

My program shells to a 3rd party consol program but never returns. I have tried both format of shell and get the same result. If I watch the process in Process explorer I see my program being launched then shelling to the 3rd party program (which appears as a child) then the 3rd party finishes and both programs close.

[Michael Mattias]

Is that the SHELL statement or the SHELL function you are using?

SHELL function returns as soon as program is launched (or failes to launch); SHELL statement does not return until the launched process ends.

Both have always worked as advertised for me.

Failing code not shown.

[Michael Mattias]

You might also try replacing the PB 'SHELL' (statement or function) with the WinAPI CreateProcess() or ShellExecuteEx().

Demo--> Win 32: Monitor Process with ShellExecuteEx June 22, 2001

[Kerry Farmer]

James

I use SHELL in the latest PBCC all the time

No issues at all.

I shell here, I shell there, I shell everywhere man.

In fact my program discipline is shelling to various programs.

My suggestion is simplify whatever you are doing down to the barebones - with a display on return - and find out what is wrong.

Show us your simplified code - ignore Michael's second message!!!!

Kerry

[James McNab]

Thanks for the input. I didn't show any code because is seemed pointless buut as you asked

SHELL(CmdString)

I tried both statement and function.I'm very new to CC but can the shelled app close the "session" (I don't suppose thats the correct term)? 've just realized that the 3rd party vendor made the source available, unfortunatley in C but I may be able to understand enough to see how it terminates. In the meantime I'll try MM suggestion.

[Dale Yarker]

That is not a compilable demo that shows the failure.

Anyway, that is SHELL statement, which suspends the calling program.

If you do not want to suspend the calling program you need the SHELL function. The form is-

PID??? = SHELL(commandstr$)

Does not matter if you want the process ID dword, That is what tells the compiler you want the function version of SHELL instead of the statement. If you had posted compilable demo code in first post, then second post would have been answer to problem (in this case). THAT IS THE POINT!!!!!!!!

[Steve Hutchesson]

James,

It is understandable if you are reasonably new to PBCC but the distinction is between "synchronous" and "asynchronous" operation of the external program being called. SHELL as a statement emulates the old DOS process of suspension of the caller to run the external or child process. With Windows being a multitasking environment you have the option of just starting another process (application in this instance) that is not synchronised to the caller and this is an asynchronous operation.

Now to test something like this, you can do it in a few lines of code in PBCC.

StdOut "Shelling to another app now"
SHELL "otherapp.exe"
StdOut "Hi, I have returned from the other app"

It is AFTER the second "StdOut" that your next code should occur.

[Dale Yarker]

Question -

How many console windows open? Guessing without any code from you, I made two PBCC programs. One to be called, and one to call the first by SHELL (both ways). They both print to a single console window. Is that what you are seeing?

[James McNab]

I understand the difference between sync and async as a consequence of using SHELL as a statement or a function, in both cases I experience the same problem. My aim it to "launch" the 3rd party software and process the error code returned, obviously syncronous so I used the the statement.

BTW I have used SHELL as both a statement and as a function in PBWin without a problem, it seems to me the problem is a console app shelling to another console app.

It is not possible to create a compilable example that may be reproduced elsewhere as you do not have the third party hardware or software.

Dale, yes they print to same window, when the 3rd party finishes the window closes immediately. There is one window open but 2 processes.

Steve, I'm not reasonable new to PBCC, I'm positively virginal as in "It's my first time".

I tried creating a batch file with the CmdString followed by a message. If I shelled to the batch file from a CC program I did not see the text (it failed) but if ran the batch manually from a console the text was displayed, success.

Is it possible to force the shelled programme to open a separate window?

I'm going to try shelling to a command console and passing it the command string as a parameter (if I can figure out how to do that). Failing that replacing the CC programme with a PBWin equivalent.

[Steve Hutchesson]

James,

It sounds like something is going wrong with the 3rd party app rather than your own app. As far as the batch file, try a "pause" before exit to see if it stops so you can see any results.

[Kerry Farmer]

James

1 Shell out to some other program and see if that works. Either SHELL out to something like WORD or to another program which all it does is displays a message eg PRINT "I am here":WAITKEY$

2 Show us your command line

3 Add Steve's displays (you can use PRINT!) You can print messages to know where you are. You can print TIME$ before and after.

4 Check for errors - I never SHELL without checking for the status of ERR

Simplify, simplify, simplify until it works than complicate it up again

ps you can turn off the console if you like - might uncomplicate the problem (#CONSOLE OFF)

[Dale Yarker]

Is there a x$ = WAITKEY$ in the first program to stop from exiting?

function pbmain () as long
  local A_Key as string


  if instr(command$, "1") then
    print "called by SHELL Function"
    print "Go check demoShell that line -"
    print $dq + "This line should show with ShellTo still running." + $dq
    print "does show. Enter C or c after checking to close and continue."
    WaitC:
    A_Key = waitkey$
    if A_Key = "C" or A_Key = "c" then
      exit function
    else
      goto WaitC
    end if
  elseif instr(command$, "2") then
    print "called by SHELL Statement"
    print "Line - " +$dq + "ShellTo has completed." + $dq + _
          " Should NOT appear in demoShell"
    print "till you enter G or g for go in this program."
  else
    print "Not SHELLed from demoShell. Exiting."
    sleep 4000
    exit function
  end if
  WaitG:
  A_Key = waitkey$
  if A_Key = "G" or A_Key = "g" then
    exit function
  else
    goto WaitG
  end if
end function

Now the program containing SHELL to call the above program.

#compile exe
#compiler pbcc
#dim all

function pbmain () as long
  local PID as dword
  local A_Key as string
  '
  'SHELL function demo -----------------
  print "function"
  PID = shell("c:\aProjects_PB\testMcNab\ShellTo.exe -1")
  print "Go check demoShell that -"
  print  "This line should show with ShellTo still running"
  print "m"


  'SHELL statement demo ----------------
  shell("c:\aProjects_PB\testMcNab\ShellTo.exe -2")
  print "ShellTo has completed."

  print "Type Q or q to quit."
  StartWait:
  A_Key = con.waitkey$
  if A_Key = "Q" or A_Key = "q" then
    print:print "Goodbye!"
    sleep 4000
    exit function
  else
    goto StartWait
  end if
end function

These are not complete, but they do compile and run, and are why I asked about WAITKEY$. Now we're down to post 12 just to get an accurate description of the problem. Usually your whole source code is not needed, sometimes just a PBMAIN that fails the same way your source code does. (In this case two. One with SHELL, the other to be shelled to.)

Now if adding a WAITKEY$ (or other delay) does not fix part of the problem, does anyone have an idea? Also, to force separate console windows for each program? I do not believe (at this point) that the 3rd party program is at fault.

Cheers,

[Kerry Farmer]

Now if adding a WAITKEY$ (or other delay) does not fix part of the problem, does anyone have an idea? Also, to force separate console windows for each program? I do not believe (at this point) that the 3rd party program is at fault.

debug 101 - change the 3rd party program to something simple - and see if it still happens

[James McNab]

Thanks Dale, it works now, inspired by your code, I shell to a small CC prog that shells to the 3rd party. I don't get the exit code but I can live with that.

[John Montenigro]

James,

I don't see any need to give up on getting back a return code from any program you SHELL to. (Even if it returns no code, you'll get 0...)


If you are shelling to a program that you are writing in PBWin or PBCC and you want to test an return code value upon its completion:

FUNCTION PBMAIN
   ... do whatever
   FUNCTION = 12345     ' or whatever...      'SET YOUR OWN ERRORLEVEL return code
END FUNCTION

A .BAT that runs your program can test ERRORLEVEL for that return code (12345 or whatever...)



...deleted incorrect CODE sample...



None of that "but can I live without..." stuff - this is PB!

-John

[Paul Purvis]

James. Somebody suggested to me lately to watch out for double quote characters in strings that you want to remove.
I think I used a TRIM function in a while loop to remove finds of spaces or double quote characters on the first and last character in a string.

[Dale Yarker]

You're welcome.

I don't get the exit code but I can live with that.

Of course you don't get the exit return. Doing that would require the SHELL statement, and your program would be blocked till it finished.

Cheers,

[Dale Yarker]

Paul, That double double quote and triple double quote stuff had to do with pipeing and redirection, and passing command line parameters to second or third thing on command line string in first.

John, no. Please reread help. PID is process ID of SHELLED to program, not the error level which is set at completion of that program.
There is a choise. If you want top program not to wait (asyncronous) then you use SHELL function and there is no return value. If you want a return value then you use SHELL statement and you must wait (syncronous) for shelled to program to finish.

Cheers,

[Mike Doty]

Michael Mattias has solution in my opinion in thread 3 or follow the link below.

The problem is normally the current drive xor directory is not changed to and the shelled to program requires it.
To see if this is the reason, put a batch file in the folder where the shelled to program exists and try shelling to the batch file.

test.bat
cd /d %~dp0
program.exe
pause

This links show a WaitShell example that changes the driive and directory
https://forum.powerbasic.com/forum/u...xecute-program

[Dale Yarker]

Mike, I'm sure you have an answer. But to what question? The question here was program closing too soon, and being blamed on SHELL. It was actually a missing CON.WAITKEY$ (or some or other reason for program not to close). What you say about path and batch files is probably true, but SO WHAT?