- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear all, I recently changed to Mac Os X and want to use the Fortran Compiler. I worked with Compaq Visual Fortran under Windows, however I am still new to the world of programming. I installed the the compiler and tried to compile and run a program which is based on two f90 files which depend on each other using the Terminal.
Using " ifort Sticklebackvision.f90 VisualRange.f90 " I received a file "a.out" which is recognized as UNIX executable. How do I run this one to produce my results (just some text files with numbers).
Sorry to bother you with such a basic question, but I couldn't find an easy understandable introduction in the internet. And can anyone recommend a good book in which I would find answers to questions like this?
Thanks in advance,
Jan
Using " ifort Sticklebackvision.f90 VisualRange.f90 " I received a file "a.out" which is recognized as UNIX executable. How do I run this one to produce my results (just some text files with numbers).
Sorry to bother you with such a basic question, but I couldn't find an easy understandable introduction in the internet. And can anyone recommend a good book in which I would find answers to questions like this?
Thanks in advance,
Jan
Link Copied
6 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan,
If you have a local college or university or decent bookstore you may find a "... for Dummys". (OS/X for Dummys, Linux for Dummys, Unix for, Dummys, ...). Beginner type of books. Hopefully one will also have beginner programmers info as well.
Look in the table of contents for:
Command line syntax
Make file ...
Directory layout...
Personally I am not a Linux user. The command line differences between Linux and MS DOS (and console windows in Windows)to a limited degree is the transpositioni of "/" and "".
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan,
I forgot to add....
Use Google and enter into the search line
linux command line syntax
You will get some good links.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
To run the program, type:
./a.out
I am not experienced in Linux, but as I understand it, the default PATH does not include the current directory, represented as ".".
To change the name of the output file, use the -o switch, for example:
ifort -o myprog source1.f90 source2.f90
and to run:
./myprog
Note that on Linux/UNIX, executables often have no file type at all.
./a.out
I am not experienced in Linux, but as I understand it, the default PATH does not include the current directory, represented as ".".
To change the name of the output file, use the -o switch, for example:
ifort -o myprog source1.f90 source2.f90
and to run:
./myprog
Note that on Linux/UNIX, executables often have no file type at all.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
1. For the record, the original poster said he was using MacOS X, not Linux. However, that doesn't change the baisc validity of your reply.
2. The default path is not uniform for all such machines. It is controlled by your system administrator. If this is a personal machine with no system administrator other than yourself, then you are likely using the default for the default as determined by the distribution. (For MacOS, the distribution is controlled by Apple, but for Linux there are many distributions and thus many different groups making this decision.)
3. [Minor aside, if your system administrator has changed your shell from a Bourne style shell like bash to C-shell style shell like tcsh, then the "PATH" environment variable is controlled by the "path" shell variable. (C-shell style shells are still popular in some organizations because the early Bourne style shells were much less convenient to use interactively. This is not a problem with modern Bourne style shells, but some organizations have a tradition of using C-shell style shells dating back to when it was a problem.)]
4. Even if "." is in your PATH, you should exercise care in choosing to type "myprog" rather than "./myprog", because there may exist a file with the same name in a different directory earlier in your PATH. The classic example of this is when someone chooses the name "test" for test program, not realizing that there is a standard Unix command by that name. A less common but more mystifying example I have encountered is when a system administrator inadvertently leaves a file named "a.out" in one of the standard command directories.
5. Steve's last comment might be misinterpreted, so I will restate in different words: Unlike Windows, where the names of normal executables always end in ".EXE", in Unix and Unix-like operating systems (including Linux and MacOS X), no such naming convention applies. Indeed, while it would be entirely possible to name all your executables with names ending in ".exe", the typical programmer does not do so. It is far more typical to compile a source file named something like "myprog.f", "myprog.f90", or "myprog.c" into an executable named just plain "myprog" than it is to call the executable "myprog.exe" or "myprog.out".
-Kurt
2. The default path is not uniform for all such machines. It is controlled by your system administrator. If this is a personal machine with no system administrator other than yourself, then you are likely using the default for the default as determined by the distribution. (For MacOS, the distribution is controlled by Apple, but for Linux there are many distributions and thus many different groups making this decision.)
3. [Minor aside, if your system administrator has changed your shell from a Bourne style shell like bash to C-shell style shell like tcsh, then the "PATH" environment variable is controlled by the "path" shell variable. (C-shell style shells are still popular in some organizations because the early Bourne style shells were much less convenient to use interactively. This is not a problem with modern Bourne style shells, but some organizations have a tradition of using C-shell style shells dating back to when it was a problem.)]
4. Even if "." is in your PATH, you should exercise care in choosing to type "myprog" rather than "./myprog", because there may exist a file with the same name in a different directory earlier in your PATH. The classic example of this is when someone chooses the name "test" for test program, not realizing that there is a standard Unix command by that name. A less common but more mystifying example I have encountered is when a system administrator inadvertently leaves a file named "a.out" in one of the standard command directories.
5. Steve's last comment might be misinterpreted, so I will restate in different words: Unlike Windows, where the names of normal executables always end in ".EXE", in Unix and Unix-like operating systems (including Linux and MacOS X), no such naming convention applies. Indeed, while it would be entirely possible to name all your executables with names ending in ".exe", the typical programmer does not do so. It is far more typical to compile a source file named something like "myprog.f", "myprog.f90", or "myprog.c" into an executable named just plain "myprog" than it is to call the executable "myprog.exe" or "myprog.out".
-Kurt
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
MacOS X is UNIX (BSD) underneath and most of the typical UNIX conventions apply. However, there are often subtle (and sometimes not-so-subtle) differences between UNIX variants and, more so, Linux variants.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello together,
Thanks a lot for your quick help and all the hints. Now it works, and I will also try to become acquainted with the unix commands now. Thanks again.
Jan
Thanks a lot for your quick help and all the hints. Now it works, and I will also try to become acquainted with the unix commands now. Thanks again.
Jan
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page