on CALL system('command') from Fortran
Nasser M. Abbasi
gfortran 4.6:
I was trying to see if I can call gnuplot from fortran to make a plot.
But it seems system() is not an intrinsic that is supported in
gfortran other than when using std=gnu. Googling around, it seems
this was rejected for being added to f2003, but may be in the
future it will be added?
It is VERY useful intrinsic to have.
Also, I am not sure if when using std=gnu, if this will also allow one
to also use the newer features of Fortran or not.
I normally compile with std=f2003, but now have to compile with
std=gnu just to be able to use CALL system().
If someone knows of a trick to call system from Fortran, while using
std=f2003 that will be good.
-----------------------
$ cat t.f90
program t
implicit none
CALL system('ls')
end program t
------------------------
$ gfortran -std=gnu t.f90
$ gfortran -std=f2008 t.f90
/tmp/ccabIjiv.o: In function `MAIN__':
t.f90:(.text+0x16): undefined reference to `system_'
collect2: ld returned 1 exit status
thanks
--Nasser
Richard Maine
> If someone knows of a trick to call system from Fortran, while using
> std=f2003 that will be good.
A time machine might help in order to go back and get such a thing added
to f2003 (I tried to get such functionality in f2003, though not with
that name), but I'd agree that would indeed be a good trick. Since a
system intrinsic is not in the f2003 standard, one can reasonably expect
that if you ask the compiler to bitch about non-standard things, it
might well bitch about that. Any trick that both asks for f2003
compliance, but fails to catch that one would probably count as a bug.
Although....
You could use the method I (and others) recommend for many nonstandard
things, when there is something that is nonstandard, but still sometimes
worth using (and I'd agree that SYSTEM fits in that category). The
keywords are "isolate" and document.
Instead of putting something nonstandard like CALL SYSTEM directly in
the main part of your code, keep the main part perfectly standard by
having it call some procedure of your own. That procedure of your own
might well use nonstandard features, but the nonstandard usage is
isolated to that one procedure. Ideally, you might even keep such
procedures with nonstandard code in a separate file. Then document that
the procedure in question uses something nonstandard. (Such
documentation should an important part of the job, not an afterthought
that might not even get done).
If done well, this greatly simpifies porting by separating the parts
that are likely to need work from the large bulk of the program that
should compile and work in any environment. In your case, you would be
able to use std=f2003 on the main body of the code, but compile the
small nonstandard part with std=gnu.
To my knowledge, the functionality of SYSTEM is in f2008, although not
by that name (for good reason).
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
Tim Prince
> It is VERY useful intrinsic to have.
The variant where SYSTEM() is an integer function is equally common.
Maybe the F2008 version will work for you, when compilers begin to
implement it?
Tobias Burnus
> I was trying to see if I can call gnuplot from fortran to make a plot.
>
> But it seems system() is not an intrinsic that is supported in
> gfortran other than when using std=gnu.
If you want to be widely compatible, I would stick to SYSTEM - as most
compilers support. it.
Alternatively, you could use EXECUTE_COMMAND_LINE, which had been added
in Fortran 2008 and which is implemented in GCC since 4.6.
EXECUTE_COMMAND_LINE also allows asynchronous execution and is well
defined, but as it is rather new, most compiler do not support it yet
(contrary to the SYSTEM vendor intrinsic, which is widely supported).
See also:
http://gcc.gnu.org/onlinedocs/gfortran/EXECUTE_005fCOMMAND_005fLINE.html
Tobias
Ian Harvey
...
> If someone knows of a trick to call system from Fortran, while using
> std=f2003 that will be good.
! Assumes that your fortran processor has a C compiler as a"companion
processor".
PROGRAM this_will_call_system_without_std_warnings
USE, INTRINSIC :: ISO_C_BINDING, ONLY: C_CHAR, C_NULL_CHAR
IMPLICIT NONE
INTERFACE
FUNCTION whatever_you_want_to_call_it_in_fortran(command) &
RESULT(rc) BIND(C, NAME='system')
USE, INTRINSIC :: ISO_C_BINDING, ONLY: C_CHAR, C_INT
CHARACTER(KIND=C_CHAR), INTENT(IN) :: command(*)
INTEGER(C_INT) :: rc
END FUNCTION whatever_you_want_to_call_it_in_fortran
END INTERFACE
INTEGER :: rc
!****
rc = whatever_you_want_to_call_it_in_fortran( &
C_CHAR_'command-line with arguments' // C_NULL_CHAR )
END PROGRAM this_will_call_system_without_std_warnings
Daniel Carrera
> To my knowledge, the functionality of SYSTEM is in f2008, although not
> by that name (for good reason).
What is the new name? We can check whether it is supported by gfortran,
and if it is not, one could write a function with the same name to take
the place of the F2008 intrinsic until that intrinsic is implemented.
Daniel.
Daniel Carrera
Nevermind. I can see that it is EXECUTE_COMMAND_LINE and is supported
by GCC 4.6.
Personally I like "system" better. I would be tempted to write my own
wrapper and call it "system".
Daniel.
steve
> If someone knows of a trick to call system from Fortran,
> while using std=f2003 that will be good.
RTFM.
-fall-intrinsics
--
steve
steve
> Nasser M. Abbasi <n...@12000.org> wrote:
>
> > If someone knows of a trick to call system from Fortran, while using
> > std=f2003 that will be good.
>
> A time machine might help in order to go back and get such a thing added
> to f2003 (I tried to get such functionality in f2003, though not with
> that name), but I'd agree that would indeed be a good trick. Since a
> system intrinsic is not in the f2003 standard, one can reasonably expect
> that if you ask the compiler to bitch about non-standard things, it
> might well bitch about that. Any trick that both asks for f2003
> compliance, but fails to catch that one would probably count as a bug.
> Although....
>
Well, the compiler isn't bitching about a non-standard thing.
-std=f2003 restricts the set of available intrinsics to those
listed in F2003. When the linker tries to link the object code,
it is looking for an external function, which the OP did not
supply. So, compilation fails.
One minor nit, if I understand the standard (which is a
big assumption), a conforming compiler must supply the
intrinsic subprograms listed in the F2003 standard, but
it is not restricted from supplying additional subprograms.
So, technically, gfortran could include system() even with
-std=f2003. Oh, and there is -fall-intrinsics.
--
steve
dpb
> On Apr 1, 8:37 am, Daniel Carrera<dan...@gmail.com> wrote:
>> On 04/01/2011 06:00 AM, Richard Maine wrote:
>>
>>> To my knowledge, the functionality of SYSTEM is in f2008, although not
>>> by that name (for good reason).
>>
...
> Nevermind. I can see that it is EXECUTE_COMMAND_LINE ...
Wow! That's certainly a keyboard-full...wonder if could have gotten any
more verbosity builtin as well. Ah well, guess it's not _too_ likely
there are many existing apps that will conflict with it.
>
> Personally I like "system" better. I would be tempted to write my own
> wrapper and call it "system".
Me, too, but the historical baggage of too many other implementations
existing already. Still...
Hmmmm...is there any way in F03 or greater to rename intrinsics a la USE
(other than building the wrapper layer and a module and USEing it, that
is)????
--
viper-2
> Experts:
>
> gfortran 4.6:
>
> I was trying to see if I can call gnuplot from fortran to make a plot.
>
> But it seems system() is not an intrinsic that is supported in
> gfortran other than when using std=gnu. Googling around, it seems
> this was rejected for being added to f2003, but may be in the
> future it will be added?
>
> It is VERY useful intrinsic to have.
>
Having fun with Gnuplot? I'm a fan.:-)
As Tobias suggested "system"is widely supported.
I use "call system()" in C-Graph to handle graphing with Gnuplot:
<http://www.codeartnow.com/code/download/c-graph-1/c-graph-version-2-
preview>
See c-graph.F90 for some tips on plotting (I'm still a Gnuplot newbie
mind you).
Let us know if "-fall intrinsics" works for you with std=f2003. Here's
the relevant line from section 2.2 of the Gfortran manual:
-fall-intrinsics
This option causes all intrinsic procedures (including the GNU-
specific extensions) to be accepted. This can be useful with -std=f95
to force standard-compliance but get access to the full range of
intrinsics available with gfortran. As a consequence, -Wintrinsics-std
will be ignored and no user-defined procedure with the same name as
any intrinsic will be called except when it is explicitly declared
EXTERNAL.
I don't ask as many questions as I could partly because I just don't
want anyone telling me to "RTFM". Even the most prudent among us can
find it difficult to find what they're looking for in a manual. I
learnt about f90 mode from Ian Bush in this group while battling with
g77. It would have taken me a few more weeks to make the discovery by
RTFM.
The "F" in the latter is from that frackin' brilliant TV sci-fi series
"Battlestar Galactica"
I'm off to drink toffee, prepare an ambush for the cylons - and RTFM!
rofl
agt
--
Freedom - no pane, all gaiGN!
Code Art Now
http://codeartnow.com
Email: a...@codeartnow.com
Dan Nagle
On 2011-04-01 08:13:34 -0400, steve said:
>
> One minor nit, if I understand the standard (which is a
> big assumption), a conforming compiler must supply the
> intrinsic subprograms listed in the F2003 standard, but
> it is not restricted from supplying additional subprograms.
> So, technically, gfortran could include system() even with
> -std=f2003. Oh, and there is -fall-intrinsics.
The compiler may supply more intrinsics. A standard-conforming program
may not use the extended intrinsics. Hence the standard's advice
to supply an interface, or at least the external attribute,
to all user-supplied procedures.
--
Cheers!
Dan Nagle
Nasser M. Abbasi
>
> Having fun with Gnuplot? I'm a fan.:-)
>
> As Tobias suggested "system"is widely supported.
>
> I use "call system()" in C-Graph to handle graphing with Gnuplot:
> http://www.codeartnow.com/code/download/c-graph-1/c-graph-version-2-preview
>
> See c-graph.F90 for some tips on plotting (I'm still a Gnuplot newbie
> mind you).
>
THanks for the link. I tried the following fortran file from
the above site. called C-Graphv2-preview.f90
I have gfortran 4.6,
$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ./configure
Thread model: posix
gcc version 4.6.0 (GCC)
And the program I downloaded does not seem to like gcc 4.6 too
much, as it keeps crashing. I was trying it. FYI below is
examples. You might want to check this on your end.
I am running this on mint linux 2.6.35-28
thanks
--Nasser
$ gfortran C-Graphv2-preview.f90
-rwxrwxrwx 1 me me 31446 2011-04-01 23:47 a.out
$ ./a.out
C-Graph version2
Enter <g> to display the GPL, or <ENTER> to continue.
Each signal is constructed from a register of Nsamples.
Periodic signals are generated with periodT. Pulses are
defined on half the period of the correspondingperiodic waveform.
Signal Code
====== ====
Sine A
Cosine B
Triangular C
Square D
Sawtooth E
Unit-Exponential F
Unit-Ramp G
Unit-Step H
Enter the number of data points "N" for the signals.
C-Graph:>> 10
The number of samples "N" is: 8 . You entered: 10
Choose first signal
C-Graph:>> A
Is the signal periodic or is it a pulse?
Type "w" for periodic wave, or "p" for pulse
C-Graph:>> w
Select the number of data samples in period T
C-Graph:>> 2
Segmentation fault
----------------------------
$ ./a.out
Signal Code
====== ====
Sine A
Cosine B
Triangular C
Square D
Sawtooth E
Unit-Exponential F
Unit-Ramp G
Unit-Step H
Enter the number of data points "N" for the signals.
C-Graph:>> 100
The number of samples "N" is: 128 . You entered: 100
Choose first signal
C-Graph:>> A
Is the signal periodic or is it a pulse?
Type "w" for periodic wave, or "p" for pulse
C-Graph:>> w
Select the number of data samples in period T
C-Graph:>> 10
*** glibc detected *** ./a.out: corrupted double-linked list: 0x09d613b8 ***
======= Backtrace: =========
/lib/libc.so.6(+0x6c501)[0x2f5501]
/lib/libc.so.6(+0x6de33)[0x2f6e33]
/lib/libc.so.6(cfree+0x6d)[0x2f9e5d]
/usr/local/lib/libgfortran.so.3(+0xad130)[0x1bd130]
======= Memory map: ========
00110000-0020e000 r-xp 00000000 08:01 664201 /usr/local/lib/libgfortran.so.3
0020e000-0020f000 rw-p 000fe000 08:01 664201 /usr/local/lib/libgfortran.so.3
0020f000-00210000 rw-p 00000000 00:00 0
00210000-00282000 r-xp 00000000 08:01 664190 /usr/local/lib/libquadmath.so.0
00282000-00283000 rw-p 00071000 08:01 664190 /usr/local/lib/libquadmath.so.0
00289000-003e0000 r-xp 00000000 08:01 3405247 /lib/libc-2.12.1.so
003e0000-003e2000 r--p 00157000 08:01 3405247 /lib/libc-2.12.1.so
003e2000-003e3000 rw-p 00159000 08:01 3405247 /lib/libc-2.12.1.so
003e3000-003e6000 rw-p 00000000 00:00 0
00a9e000-00a9f000 r-xp 00000000 00:00 0 [vdso]
00b13000-00b2f000 r-xp 00000000 08:01 3405244 /lib/ld-2.12.1.so
00b2f000-00b30000 r--p 0001b000 08:01 3405244 /lib/ld-2.12.1.so
00b30000-00b31000 rw-p 0001c000 08:01 3405244 /lib/ld-2.12.1.so
00b37000-00b5b000 r-xp 00000000 08:01 3405251 /lib/libm-2.12.1.so
00b5b000-00b5c000 r--p 00023000 08:01 3405251 /lib/libm-2.12.1.so
00b5c000-00b5d000 rw-p 00024000 08:01 3405251 /lib/libm-2.12.1.so
00d61000-00d7d000 r-xp 00000000 08:01 664173 /usr/local/lib/libgcc_s.so.1
00d7d000-00d7e000 rw-p 0001b000 08:01 664173 /usr/local/lib/libgcc_s.so.1
08048000-0804f000 r-xp 00000000 00:13 68 /media/sf_nabbasi/data/Fortran_related/a.out
0804f000-08050000 rw-p 00006000 00:13 68 /media/sf_nabbasi/data/Fortran_related/a.out
09d5c000-09d7d000 rw-p 00000000 00:00 0 [heap]
b7600000-b7621000 rw-p 00000000 00:00 0
b7621000-b7700000 ---p 00000000 00:00 0
b77a1000-b77a3000 rw-p 00000000 00:00 0
b77b9000-b77bb000 rw-p 00000000 00:00 0
bfd01000-bfd22000 rw-p 00000000 00:00 0 [stack]
Aborted
Louis Krupp
Just for fun, compile C-Graphv2-preview.f90 with array bounds checking
turned on and then run it.
Louis
viper-2
wrote:
> On 4/2/2011 12:55 AM, Nasser M. Abbasi wrote:
>
> > On 4/1/2011 8:04 AM, viper-2 wrote:
>
> >> Having fun with Gnuplot? I'm a fan.:-)
>
> >> As Tobias suggested "system"is widely supported.
>
> >> I use "call system()" in C-Graph to handle graphing with Gnuplot:
The preview file isn't much fun except for compiling with array bounds
checking etc.:-)
You might get segfaults when compiling with certain options as I had
problems updating gdb on my old RedHat 8.0 system and haven't yet
tested with gdb on my current Debian Lenny. I got segfaults earlier
compiling with O2, but with O0 and my current gcc 4.3.2 I don't have
any problems when compiling without bounds checking or other fancy
stuff.:-)
I'm busy writing the supplementary files for the build right now
(THANKS, license and so on). Further debugging is scheduled for after
I'm through with the re-commenting exercise.
Thanks for the feedback!
viper-2
> On 4/1/2011 8:04 AM, viper-2 wrote:
>
>
>
> > Having fun with Gnuplot? I'm a fan.:-)
>
> > As Tobias suggested "system"is widely supported.
>
> > I use "call system()" in C-Graph to handle graphing with Gnuplot:
>
> > See c-graph.F90 for some tips on plotting (I'm still a Gnuplot newbie
> > mind you).
>
> THanks for the link. I tried the following fortran file from
> the above site. called C-Graphv2-preview.f90
>
> I have gfortran 4.6,
>
> $ gfortran -v
> Using built-in specs.
> COLLECT_GCC=gfortran
> COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper
> Target: i686-pc-linux-gnu
> Configured with: ./configure
> Thread model: posix
> gcc version 4.6.0 (GCC)
>
> And the program I downloaded does not seem to like gcc 4.6 too
> much, as it keeps crashing. I was trying it. FYI below is
> examples. You might want to check this on your end.
>
> I am running this on mint linux 2.6.35-28
Nasser, try the F90 file in c-graph-2.0.March.16.2011.tar.gz. You'll
find more Gnuplot commands there.
Thanks for the feedback, I got segfaults myself earlier:
<https://groups.google.com/group/comp.lang.fortran/browse_thread/
thread/383fd9107b4783b5?hl=en>
But with gcc 4.3.2 and no additional compile options C-Graph gives no
problems. There are further tests to run with gdb and so on. I'm
writing supplementary text files at the moment.
There's also a Gnuplot group "comp.graphics.apps.gnuplot" in case you
want help:
<http://groups.google.com/group/comp.graphics.apps.gnuplot/topics?lnk>
I've been meaning to post a question there about "pause -1" which
seems to have a problem when used in multiplot mode. Just haven't had
the time yet - too busy RTFMs.
:-)
Gary L. Scott
"system" however. It is a highly ambiguous name. What you typically
want is a command line interpreter/processor of some sort. "system"
doesn't connote that to me. In addition, a system may provide several
command line processors to choose from and a method to choose among them
would be important to have on those systems.
Some systems also have peculiar behavior that might need to be
suppressed or enabled such as on windows where if you don't indicate to
suppress it, a console window pops up, even if you haven't written
anything to a console window.
To me, the term "system" just means I'm making a "system call" which
would be to any one of 100s or 1000s of APIs.
While the standard chosen name is WAY TOO LONG, it more accurately
describes the functionality than "system".
viper-2
>
> I've been meaning to post a question there about "pause -1" which
> seems to have a problem when used in multiplot mode.
The problem in Gnuplot multiplot mode is not "pause -1" but "pause
<time>". I get the pause for the first plot but not for subsequent
plots in multiplot mode.
This is just to make a correction. I don't expect a reply, I know it's
off topic.
Richard Maine
> It is a very useful feature. I don't particularly like calling it
> "system" however. It is a highly ambiguous name....
> To me, the term "system" just means I'm making a "system call" which
> would be to any one of 100s or 1000s of APIs.
>
> While the standard chosen name is WAY TOO LONG, it more accurately
> describes the functionality than "system".
I agree on all of those grounds (including the ones I elided). There is
no danger that the standard would have used the name system, even if
everyone had thought it a great name. It would have broken too many
existing codes that use "SYSTEM" now because there are multiple
incompatible variants of the exact form. It is easier to adopt a new
name that doesn't conflict with anything likely to already be in
widespread use.
I also agree that the standard's one is longer than I'd have preferred.
glen herrmannsfeldt
(snip on the standard replacement for system())
> I also agree that the standard's one is longer than I'd have preferred.
Another good use for statement functions.
-- glen
Dan Nagle
On 2011-04-02 17:10:40 -0400, Richard Maine said:
>
> I also agree that the standard's one is longer than I'd have preferred.
I'm not sure I recall the discussion clearly, but
I think we felt we already had the words "command line"
in other intrinsics, so we needed a variant on that.
The original command line wars were part of f03. :-)
If it's really too long, program your editor to write it for you.
Isn't 'exe' unique as beginning letters in Fortran?
--
Cheers!
Dan Nagle
Ron Shepard
nos...@see.signature (Richard Maine) wrote:
> Gary L. Scott <garyl...@sbcglobal.net> wrote:
>
> > It is a very useful feature. I don't particularly like calling it
> > "system" however. It is a highly ambiguous name....
> > To me, the term "system" just means I'm making a "system call" which
> > would be to any one of 100s or 1000s of APIs.
> >
> > While the standard chosen name is WAY TOO LONG, it more accurately
> > describes the functionality than "system".
>
> I agree on all of those grounds (including the ones I elided). There is
> no danger that the standard would have used the name system, even if
> everyone had thought it a great name. It would have broken too many
> existing codes that use "SYSTEM" now because there are multiple
> incompatible variants of the exact form. It is easier to adopt a new
> name that doesn't conflict with anything likely to already be in
> widespread use.
>
> I also agree that the standard's one is longer than I'd have preferred.
It looks like the standard subroutine has enough functionality to
allow the programmer to write his own system() subroutine. In this
case, you could fix your code simply by writing one new subroutine,
and you don't have to go through and track down and change all of
the old system() calls.
If you only call it once, it really doesn't matter how long the name
is.
$.02 -Ron Shepard