I would add that
system is not a good choice for portability due to the (slightly) different implementation in different compilers. For example Intel fortran doesn't accept the
call system variation and some compilers act differently on windows and Linux machines, since some windows libraries inherited the DEC's
systemqq call. Not to mention the
system function is not part of the Fortran standard.
On the other hand, the Fortran 2008 introduces the subroutine
execute_command_line and it is the statement advised for future compatibility. Example:
Code:
PROGRAM test_system_call
IMPLICIT NONE
INTEGER :: status
CALL execute_command_line('file1', exitstat = status)
WRITE(*,*) 'exit status of the command is', status
END PROGRAM test_system_call
This code assumes that the operating system is aware of the file1 command, that is it resides in one of the directories listed in the PATH environment variable. On the contrary, put the full path, as previously suggested:
Code:
CALL execute_command_line('/path/to/file1', exitstat = status)
Nevertheless, the Fortran 2008 standard is not fully accepted by all the fortran compilers, therefore we have to wait some more time before they align.
Instead, my suggestion is to recompile the source code of
file1 after having transformed it in a fortran MODULE containing FUNCTIONS and/or SUBROUTINES. In this way, the calling program can use it and its functions by means of a USE statement at the beginning of your code and nothing else. For example, suppose you have a MODULE named
my_utilities and a FUNCTION inside it named
file_one; the calling program will be:
Code:
PROGRAM test_module
USE my_utilities
IMPLICIT NONE
INTEGER :: result
result = file_one(list of arguments)
WRITE(*,*) result
END PROGRAM test_module
This topic is too far extensive to be covered here, but if you follow a good Fortran reference, MODULES are the way to go (and the chapter to read). Just my
Fortran alternative to Matlab 'system' command
