ExecFile()

BlitzPlus Forums/BlitzPlus Programming/ExecFile()

PantsOn(Posted 2003) [#1]
Hi

how do I execute an external program using the above command with a command line parameters??

cmd$ = "echo hello"
execfile(cmd$)

the above runs echo, but doesn't pass the command line params

I have even tried
cmd$ = chr(34) + "echo hello" + chr(34)
execfile(cmd$)

that above just tries to execute a program called 'echo hello' as one filename

anyone else having the same problems??
or is there something I'm obviously doing wrong..
PS all directorys are correct and files present


Kevin_(Posted 2003) [#2]
Try using the command processor that runs DOS stuff. In XP it is cmd.exe, dont know what is it in ME/2K.

Regards


Odds On(Posted 2003) [#3]
try

cmd$ = chr(34) + "echo" + chr(34) + " hello"
execfile(cmd$)


you could also try echo.exe.. if that doesn't work you're probably sending the command line parameter differently to how echo reads it.


soja(Posted 2003) [#4]
PantsOn:
What OS are you using? When I do that, nothing happens -- no new window, no echo whatsoever. (Mine is XP.)

Prof:
In al 9x variants (95, 98, ME, etc) it's command.com. In all NT variants (4, 2K, XP, etc) it's cmd.exe.

Fullernator:
FYI, echo is a built-in command of the shell -- there is no external executable called echo.exe.


Mark Tiffany(Posted 2003) [#5]
You might wish to try CreateProcess - this does the same as ExecFile, but returns a stream that you can interrogate for program output. I think it may have been documented online now...


PantsOn(Posted 2003) [#6]
Might have to explain a bit better..
above was just an example.. I am not actually calling the echo command at all.

I have written a blitz prog that can have commandline parameters. But when I call it using the ExecFile method it doesn't work.

Many thanks for your help anyway... I'll try this Creatprocess command
cheers


PantsOn(Posted 2003) [#7]
No, that didn't work....
the docs for Execfile say to put quotes round..
http://www.blitzbasic.co.nz/bpdocs/command.php?name=ExecFile&ref=2d_a-z

Is anyone else experiencing problems calling programs with parameters????

PS I'm on W2K, P4


soja(Posted 2003) [#8]
I'm not experiencing problems calling programs with parameters. For example, this works fine:
cmd$ = "notepad newfile.txt"
ExecFile(cmd)

...as does:
cmd$ = "cmd /k cd c:\"
ExecFile(cmd)


Do you have spaces in your path? If so, you'll have to use quotes, like this:
cmd$ = Chr$(34)+"c:\program files\blitzplus\program.exe"+Chr$(34)+" param1 param2"
ExecFile(cmd)


Finally, are you sure you're handling command line parameters correctly?


PantsOn(Posted 2003) [#9]
will try again...
command line parameters are fine.. as I can runthe program with params from command line fine...

back to drawing board...


soja(Posted 2003) [#10]
So... hmm.. are you saying that your program doesn't handle the command line parameters you pass it?

Make sure you tokenize what CommandLine$() returns, and remember it's case sensitive to compare strings, so use Upper$() or Lower$().

Or are you saying it's sorted?

(I'm a little confused with "...are fine..." and "back to the drawing board".) =)


Oldefoxx(Posted 2003) [#11]
ExecFile shells out of windows. meaning it leaves the GUI environment, to perform a command line function, which you are passing to it as a string. The fact is though, that the Win95/98/Me Command.com program does not behave in the same manner as the Cmd.exe file used in the NT version of Windows. Command recognizes parameters, such as programs to execute (followed by their own parameters), or switches, such as /k, which effect the behavior of Command. For instance, Command /K is often used to keep the DOS window open so that you have to close it manually.

Cmd.exe dose not respond to parameters, and otherwise acts like Command /K, as it does not allow the DOS window to close automatically.

Because Shell processes actually initiate new instances of the Command or Cmd interpreters, you can expect some differences in the way programs act when you shell to them, or attempt to pass parameters to them. By playing around with the Start/Run/Command ( or for NT platforms, Start/Run/Com), you will get some idea of what works and how. For instance, using Start/Run/Cmd Notepad, a DOS windows opens, but notepad is not executed. On the other hand, enter Start/Run/Notepad Now is the Time, and Notepad not only opens, but it checks to see if it can open a file called Now is the Time.

As also pointed out, you can generate a batch file (with a .BAT extension) that sets forth commands with their parameters, and then execute that. As kludgy as this seems, it often provided a method of doing something that
would be hard to achieve otherswise. For instance, if your program was initiated by a Call statement in a batch file, when you exit your program the batch file resumes execution. You cannot modify this batch file directly, but if it were set up to then call a second batch file after your program exits, you can modify that second batch file to do whatever your program wants it to do once your program terminates. (You can't modify the first batch file because it is already loaded into memory, and your changes would only effect the copy that is on the hard drive. But the second batch file has het to be loaded into memory because it has not been called yet).

The use of batch files can be helpful to initiating programs that have to be loaded and run in sections. With a lot of memory at your disposal, this may not be an important point. But let's say you were writing a program that involves multiple levels, then you might want to design it so that only one level needs to be loaded to be worked on or played at a time. Batch files are easy to modify (since they are essentially plain text files) to retain parameters related to individual users, or game levels, or what have you. Just because they are primitive does not mean that they aren't useful.


soja(Posted 2003) [#12]
Cmd.exe dose not respond to parameters, and otherwise acts like Command /K, as it does not allow the DOS window to close automatically.
On the contrary, cmd.exe has more parameters available to it than command.com.

Just try "cmd /?".

To close automatically, the /c parameter works just like it does with command.com.

I thought you'd like to know -- you seem quite genuine in your dialog and thoughtful replies.