topic Redirection is all handled by in Intel® Fortran Compiler

How to run *.exe file from fortran

Reda_A_ — Fri, 30 May 2014 02:07:50 GMT

Dear all,

Now I have a file with extension *.exe has been created using matlab, and I would like to know how I can run it from my fortran code.

Regards

The standard way, introduced

Craig_Dedo — Fri, 30 May 2014 02:42:18 GMT

The standard way, introduced with Fortran 2008. is

[fortran]

Call Execute_Command_Line ( Command, Wait, Exitstat, Cmdstat, Cmdmsg )

[/fortran]

Hope this helps.

Try the Windows

Anthony_Richards — Fri, 30 May 2014 07:04:35 GMT

Try the Windows ShellExecuteEx command, or the Quickwin SYSTEMQQ command.

ShellExecute is the way I

Steven_L_Intel1 — Fri, 30 May 2014 13:08:18 GMT

ShellExecute is the way I would recommend. See Win32 Corner - ShellExecute Intel Fortran does not yet support EXECUTE_COMMAND_LINE.

Quote:Steve Lionel (Intel)

Craig_Dedo — Sat, 31 May 2014 12:33:57 GMT

Steve Lionel (Intel) wrote:

ShellExecute is the way I would recommend. See Win32 Corner - ShellExecute Intel Fortran does not yet support EXECUTE_COMMAND_LINE.

Thanks for letting us know that IVF does not yet support Execute_Command_Line. It was late two nights ago when I answered and I did not want to take the time to find out whether or not it had been implemented.

That said, it is very unfortunate that IVF does not support Execute_Command_Line. Every OS on the market now has a non-standard way of providing this functionality. It seems to me that implementing Execute_Command_Line would be a fairly easy and low-cost feature to implement.

I did say "yet". As it

Steven_L_Intel1 — Sat, 31 May 2014 16:00:23 GMT

I did say "yet". As it happens, I've spent the past couple of weeks working on an implementation of EXECUTE_COMMAND_LINE. The trivial implementation just calling "system" is easy, sure, but Windows users wouldn't like a console window popping up all the time, which is what you get that way. To implement this in a more suitable fashion was somewhat more complex, but it's done. It will probably appear in the 15.0 compiler. (I say "probably" because the integration isn't done yet. But we're working on it.)

Yea, there are some tricky

jimdempseyatthecove — Sat, 31 May 2014 19:14:49 GMT

Yea, there are some tricky nuances such as how to handle pipe, redirect in, redirect out, and modifying environment and/or current directory and/or current drive. This is not an easy job, especially with different opinions as to what is the proper way of doing this. You have my sympathy.

Jim Dempsey

Redirection is all handled by

Steven_L_Intel1 — Sun, 01 Jun 2014 01:02:25 GMT

Redirection is all handled by the command shell. As for pipes, unless you've already redirected standard input/output to pipes, EXECUTE_COMMAND_LINE isn't going to do it for you. Modifying environment? Nope. All commands happen in a separate process, so any environment changes get thrown away when the process exits.

Basically, on Windows we use CreateProcess to do a "cmd.exe /C your-command" and, if requested, wait for the process to finish. CreateProcess is told to hide any window created (but if you run a program that creates its own window, that is displayed.) A complication I wasn't aware of until I got well into this is that, despite the CreateProcess documentation saying you should specify "cmd.exe" as the application name, that doesn't work. Instead you have to translate the COMSPEC environment variable to get the full path to the command shell processor.

On Linux and OS X it just calls the C "system" function, with a trailing & if not asked to wait. Much simpler, but you always get a console window, unless you're running from one, which on those platforms is 99.9% of the time.

The nice thing about EXECUTE_COMMAND_LINE is that it gives you the choice of waiting or not and getting the exit status. Not to mention that it's standard Fortran.

Thanks all for your kindly

Reda_A_ — Mon, 02 Jun 2014 09:32:18 GMT

Thanks all for your kindly replies,

Steve, I would like to ask you a question,

How I can let FORTRAN read my file path without add it every time step by hand using Win32 Corner - ShellExecute .

Regards

Steve,

jimdempseyatthecove — Mon, 02 Jun 2014 12:26:48 GMT

Steve,

>>Instead you have to translate the COMSPEC environment variable to get the full path to the command shell processor.

FWIW On Windows you also have the start program/command. Try running

"START your command"

Type "START /?" for syntax.

START /MIN /WAIT FooBar arg arg

Or for something completely different

del xxx.lst (pre-delete a junk file name that you pick)

dir xxx.lst (confirm file not present)

start /min cmd /c dir>xxx.lst

Note that this appears to do nothing

dir xxx.lst (should show file xxx.lst, which if TYPE'd shows directory listing produced by prior command)

When you see the options available to START, you might find some them useful.

Starts a separate window to run a specified program or command.

"title" Title to display in window title bar.
path Starting directory.
B Start application without creating a new window. The
application has ^C handling ignored. Unless the application
enables ^C processing, ^Break is the only way to interrupt
the application.
I The new environment will be the original environment passed
to the cmd.exe and not the current environment.
MIN Start window minimized.
MAX Start window maximized.
SEPARATE Start 16-bit Windows program in separate memory space.
SHARED Start 16-bit Windows program in shared memory space.
LOW Start application in the IDLE priority class.
NORMAL Start application in the NORMAL priority class.
HIGH Start application in the HIGH priority class.
REALTIME Start application in the REALTIME priority class.
ABOVENORMAL Start application in the ABOVENORMAL priority class.
BELOWNORMAL Start application in the BELOWNORMAL priority class.
NODE Specifies the preferred Non-Uniform Memory Architecture (NUMA)
node as a decimal integer.
AFFINITY Specifies the processor affinity mask as a hexadecimal number.
The process is restricted to running on these processors.

The affinity mask is interpreted differently when /AFFINITY and
/NODE are combined. Specify the affinity mask as if the NUMA
node's processor mask is right shifted to begin at bit zero.
The process is restricted to running on those processors in
common between the specified affinity mask and the NUMA node.
If no processors are in common, the process is restricted to
running on the specified NUMA node.
WAIT Start application and wait for it to terminate.
command/program
If it is an internal cmd command or a batch file then
the command processor is run with the /K switch to cmd.exe.
This means that the window will remain after the command
has been run.

If it is not an internal cmd command or batch file then
it is a program and will run as either a windowed application
or a console application.

parameters These are the parameters passed to the command/program.

NOTE: The SEPARATE and SHARED options are not supported on 64-bit platforms.

Specifying /NODE allows processes to be created in a way that leverages memory
locality on NUMA systems. For example, two processes that communicate with
each other heavily through shared memory can be created to share the same
preferred NUMA node in order to minimize memory latencies. They allocate
memory from the same NUMA node when possible, and they are free to run on
processors outside the specified node.

start /NODE 1 application1.exe
start /NODE 1 application2.exe

These two processes can be further constrained to run on specific processors
within the same NUMA node. In the following example, application1 runs on the
low-order two processors of the node, while application2 runs on the next two
processors of the node. This example assumes the specified node has at least
four logical processors. Note that the node number can be changed to any valid
node number for that computer without having to change the affinity mask.

start /NODE 1 /AFFINITY 0x3 application1.exe
start /NODE 1 /AFFINITY 0xc application2.exe

If Command Extensions are enabled, external command invocation
through the command line or the START command changes as follows:

non-executable files may be invoked through their file association just
by typing the name of the file as a command. (e.g. WORD.DOC would
launch the application associated with the .DOC file extension).
See the ASSOC and FTYPE commands for how to create these
associations from within a command script.

When executing an application that is a 32-bit GUI application, CMD.EXE
does not wait for the application to terminate before returning to
the command prompt. This new behavior does NOT occur if executing
within a command script.

When executing a command line whose first token is the string "CMD "
without an extension or path qualifier, then "CMD" is replaced with
the value of the COMSPEC variable. This prevents picking up CMD.EXE
from the current directory.

When executing a command line whose first token does NOT contain an
extension, then CMD.EXE uses the value of the PATHEXT
environment variable to determine which extensions to look for
and in what order. The default value for the PATHEXT variable
is:

.COM;.EXE;.BAT;.CMD

Notice the syntax is the same as the PATH variable, with
semicolons separating the different elements.

When searching for an executable, if there is no match on any extension,
then looks to see if the name matches a directory name. If it does, the
START command launches the Explorer on that path. If done from the
command line, it is the equivalent to doing a CD /D to that path.

Jim Dempsey

START is a shell command, so

Steven_L_Intel1 — Mon, 02 Jun 2014 14:33:00 GMT

START is a shell command, so you can't run it directly with CreateProcess, and then you run into the same issue with locating cmd.exe. Or were you suggesting using START with a call to system? I think that by the time you get to the START command, it's too late to suppress the window.

Reda, I don't understand your question. I don't see any mention of file path in the discussion of ShellExecute.

I made a test program using

jimdempseyatthecove — Mon, 02 Jun 2014 15:36:01 GMT

I made a test program using SYSTEMQQ. This seems to work (somewhat). It has an issue with >

The program runs systemqq("start cmd.exe /c dir > xxx.lst"), xxx.lst is created, but has length of 0. So the console output is not being redirected.

Jim Dempsey

I already tested redirection

Steven_L_Intel1 — Mon, 02 Jun 2014 15:39:11 GMT

I already tested redirection of dir in the new implementation and it works. I don't see any need to change it at this point.

When I looked this issue up

dboggs — Thu, 12 Jun 2014 20:30:38 GMT

When I looked this issue up in the Fortran Help a few months ago, I found the following built-in relevant procedures:

SYSTEM, SYSTEMQQ, RUN, RUNQQ

Descriptions of these were not very clear or distinguished, but I do recall that (a) the QQ versions could be used to run a .exe program while the others were just for a command-line routine (whatever that means?), and (b) all of them would wait on for the routine to complete before returning control to your program.

I didn't do thorough testing on these, so can't say I really understand them. I did however run into the following peculiarity. The program I wanted to run was Textpad.exe, and it resided in 'c:\program files'. The space in the folder name 'program files' caused trouble with SYSTEMQQ: it produced the error "cannot find folder 'c:\program' ". But RUNQQ handled it OK. So that's the routine I have used ever since.

Now the discussion above implies that there are one or two other possibilities, yet RUN and RUNQQ have not been included. Am I missing something? Is some reason why RUNQQ was not mentioned?

The only feature I would like to have that RUNQQ does not offer is for control to be returned to the program while Textpad is still in progress. But if the routine does not deal with the blank in a folder name it would not be acceptable!

Intel Fortran does not

Steven_L_Intel1 — Thu, 12 Jun 2014 21:27:17 GMT

Intel Fortran does not support a routine called RUN.

RUNQQ lets you specify the program and the command arguments separately, SYSTEM and SYSTEMQQ have you supply a command line (including program and arguments) as one argument. SYSTEM and SYSTEMQQ seem to behave identically - SYSTEM exists because it is a common C library name. All wait for command completion. You can use any of them to run a program.

On Windows, blanks in arguments are bad on the command line too, which is why you have to enclose such arguments in quotes. At least with RUNQQ, the path to the program can contain blanks.