Setting up FORTRAN

Setting up FORTRAN

11
Basic UserBasic User
11

    Sep 08, 2021#1

    I read the post about Python that was recently bumped and that helped quite a bit getting me to where I am now. But I'm just not quite there yet, I think. It might be a lack of understanding on my part about how UE works with external compilers and such. I'm running Windows 10 64-bit, latest version of UE, and using the gfortran compiler.

    What I think is supposed to happen, or I hope the way it works, is I edit the code in UE, then hit the shortcut/menu item, and a DOS window pops up and I see the command line instructions to compile the code, it complies, and then the DOS window sits there so I can execute the program to test it out. Of course, it doesn't have to be the DOS window but I don't know where/how else I would be able to tell the executable to run.

    The syntax to compile is: "gfortran filename.for -o filename", which would give me filename.exe. I can compile the code from anywhere as the compiler was added to the PATH variable. So if I compiled my little heat exchanger program, I would type at the command prompt: gfortran heatex.for -o heatex. If there are no errors, there is no output to the window. If there are errors, I'll get feedback in the DOS window.

    What happens right now is I get the DOS window to pop up temporarily, FWIW I don't see any output in the DOS window, and then it closes. UE opens another tab called 'Command Output1' (or 2, or 3, etc.) but I never see anything in that window, nor can I type any commands or anything in that window. The code does compile successfully, but I have to manually open a command prompt and CD to the location of the code to run the .exe.

    If there's an error in my code, that output does go to the Command Output tab. So that's good.

    The parameters I have are as follows (I thought I was supposed to put quotes around the command line and working directory "%" parameters but that resulted in an error), attached screenshots.

    For what it's worth, I tried adding "c:\windows\system32\cmd.exe" to the command line parameters in various configurations but either that's not going to work or I just couldn't get the syntax correct.

    Well, this gets the code compiled correctly: "gfortran heatex.for -o heatex | c:\windows\system32.exe" but the DOS window won't stay open.

    Thanks in advance for your help!

    -Matt
    Screenshot 2021-09-08 142250.png (23.45KiB)
    Screenshot 2021-09-08 142237.png (15.16KiB)
    Screenshot 2021-09-08 142222.png (17.4KiB)

    6,603548
    Grand MasterGrand Master
    6,603548

      Sep 09, 2021#2

      A user/project tool used to run a Windows console application (DOS is definitely the wrong term here) is by design for a non-interactive execution of one or more console applications with capturing the outputs written to standard output and standard error streams and display the output in an edit window or the output window in UltraEdit. Programmers use a user/project tool to run the compiler / interpreter and get its output captured to an edit window or the output window. The execution of the created executable or script with user interactions (manual input during execution) is usually done with a separate user tool as in this case capturing the output should not be done. A user working interactive with the started executable or script needs to see the output and needs to enter the input. That is not really possible with capturing the output by UltraEdit.

      Programmers use therefore usually two user/project tools. The first one is for compilation of the source code to a library or executable. That is what you tried already. I suggest following changes on already existing user tool configuration:
      1. Modify the command line to specify the compiler gfortran with its full qualified file name which means with drive + path + name + extension. Enclose the full qualified file name of the compiler in double quotes " if it contains a space or one of these characters &()[]{}^=;!'+,`~.
      2. The first argument string passed to the compiler is the name of the active file without path. This file name should be enclosed in " which means using "%n%e" in case of the name of the active file contains in future a space or one of the special characters.
      3. The third argument string passed to the compiler is the name of the active file without path and without file extension and specifies the output file name. This file name should be enclosed also in " which means using "%n" in case of the name of the active file contains in future a space or one of the special characters. If the FORTRAN compiler adds itself the suitable file extension like .exe, then it is okay to specify as name of the output file just the file name without file extension. Otherwise it would be better to use "%n.exe" as third argument.
      4. The Options are correct set whereby Save all files first is usually checked only on working with multiple source code files which are compiled all at once with a single execution of a user tool which in this case does not run just the compiler for one source code file, but a make tool which runs the compiler on a set of source code files and finally the linker on no error occurred on compilation of any source code file.
      5. For the Output the selection of Output to list box is usually the best choice for just compilation of a source code file as this results in getting the captured output written into the output window. If the compiler outputs a warning or an error message in a format understood by UltraEdit, it is possible to double click on the warning/error line in output window to set the caret in the source code file to the line with the incorrect code to fix it. See also the other commands offered by UltraEdit in context menu of the output window by right clicking on a line in an output window. It is even possible to navigate in source code file with pressing a hotkey (key combination) to previous or next line with an error in code according to previous/next warning/error line in output window.
      6. The output option Show DOS box should not be checked on running the compiler with capturing its output. That is not necessary on compiler does not prompt the user for an input which no compiler does on running it with a correct list of arguments. The standard and error output is captured by UltraEdit nevertheless and displayed in output window after the started compiler terminated itself.
      7. The option Clear output before run should be also checked with capturing the output to the output window.
      A second user tool should be used for execution of a program compiled before which is a Windows GUI application or a Windows console application which requires user input during the execution.
      1. The Command line is in this case just "%n.exe" and the working directory is defined with %p (never use double quotes for working directory) if the created executable is run always without any arguments.
      2. Save active file and Save all files first are both not needed for just starting the executable, except there is a file edited in UltraEdit which is used by the started executable as input file. DOS program should be selected on created executable is a Windows console application, Windows program should be selected if the created executable is a Windows GUI application.
      3. On tab Output it does not matter which option is selected on left side for the command output because of Capture output should be unchecked in any case on running a Windows GUI or a Windows console application with user input required during the execution. The option Show DOS box must be checked if the executable program is a console application which requires user input during the execution.
      The execution of a DOS program results always in starting in background the Windows command processor cmd.exe with the option /c to close (terminate) itself once the execution of the Command line appended as argument string(s) by UltraEdit finished. The Windows command processor uses the Windows kernel library function CreateProcess to run the executable(s) specified on the command line and yes, cmd.exe searches also for executables/scripts specified just with file name using the environment variables PATHEXT and PATH. There is left to /c additionally used the cmd.exe option /U if on tab Output capturing of the output is enabled and UTF-16 is selected if the started executable is a Windows console application which outputs in Unicode with UTF-16 encoding like wmic.exe. UltraEdit for Windows v28.10 uses additionally the CMD option /s left to /c and encloses the entire command line as specified in user/project tool configuration additionally in ", except the option Show DOS box is checked. The reason is explained on running cmd /? in a command prompt window. UltraEdit starts the program directly with the Windows kernel library function CreateProcess on Windows program selected on tab Options.

      I have never used it but it is possible to run the compiler with the Windows command processor instance started by UltraEdit on execution of the user tool and capture its output and on successful compilation without any warning or error start automatically a second instance of the Windows command processor to run the executable and keep this second instance of cmd.exe running even after compiled executable terminated itself to see the output of the executable and for whatever commands the user wants to run next via the second CMD instance after finishing the execution of the compiled executable.

      It works to use in UltraEdit for Windows v22.20 and v23.20 the test Command line

      "%SystemRoot%\System32\find.exe" "Highlight" "%ProgramFiles%\IDM Computer Solutions\UltraEdit\changes.txt" & start "Test Console" %SystemRoot%\System32\cmd.exe /D /K set

      with capturing the output to the output window which results in starting cmd.exe to run find.exe to search case-sensitive for the string Highlight in the specified text file containing at least one line with Highlight, and as find.exe with terminates itself with exit code 0 for success, start one more command process with a title for the console window and run the command set and keep this second command process running, and get the output of find.exe to first standard output stream of cmd.exe started by UltraEdit captured into the output window of UltraEdit. But the output of find.exe is not captured to the output window by using this Command line in UltraEdit for Windows v28.10 although cmd.exe is started by UltraEdit v28.10 with exactly the same arguments list as with UltraEdit v22.20. UltraEdit v28.10 does not output the captured output by executed find.exe to the output window. There is only displayed the executed command line in the output window. This is a bug in my opinion of UE v24.00.0.42 to v28.10.0.154 which I have reported to IDM support by email.

      However, the single command line can be used with capturing the output of the compiler into an edit window instead of the output window. So if you want to go with the single user tool solution, use the following settings in the user tool configuration:

      Tab Command

      Menu item name: Compile Fortran
      Command line: "C:\Path to FORTRAN\Compiler\gfortran.exe" " %n%e" -o "%n" && start "Test %n.exe" %ystemRoot%\System32\cmd.exe /D /K "%n.exe"
      Working directory: %p
      Toolbar bitmap/icon file: full qualified file name of an image file with the icon for this user tool

      Tab Options

      Program type: DOS program selected
      Save active file: checked
      Save all files first: not checked or checked if there is a reason to save all files first

      Tab Output

      Command output: Replace existing selected
      Show DOS box: not checked
      Capture output: checked
      Clear output before run: not checked
      Replace selected text with: No replace selected
      Handle output as: ANSI selected (most likely, depends on gfortran.exe)

      It is important to select Replace existing instead of Output to list box due the issue with captured output not written to the output window on compilation was successful and so a new command process is started with running the compiled executable and keep running after finishing execution of compiled executable.
      Best regards from an UC/UE/UES for Windows user from Austria

      11
      Basic UserBasic User
      11

        Sep 09, 2021#3

        First of all, double clicking on the error in the output window which takes me to the line, is BLEEPING AMAZING. That's so incredibly useful. Thank you!

        Second of all, as always, thank you for the incredibly thorough post.

        Lastly, I configured UltraEdit as you suggested; unfortunately, when I 'run' the executable I just created, the DOS window/console is not persistent, if that's the right word to use. It pops up, the program runs, and then the window closes immediately. I can see that the program did, in fact, run. HOWEVER, I am attempting to understand the second half of your post, starting with "The execution of a DOS program..." I read it once, and it's going over my head. I will re-re-re-read and when I have more questions I'll post back.

        Again, thank you thank you thank you!

        15 minutes later: Well, I spoke too soon. The solution at the bottom is not working for me. The code is not compiling if there is a mistake in it, and the mistake is not echo'd to the Output Window. (edit) I see you have also caught this and have reported it to UE.

        For now, the solution of Step 1 - compile the code, Step 2 - run the code works well for me. I did not understand/know the correct parameters to run the executable from within UE and get a persistent DOS window. So Ctrl+Shift+1, then Ctrl+Shift+2 works just peachy.

        Thanks again!

        6,603548
        Grand MasterGrand Master
        6,603548

          Sep 09, 2021#4

          The ultimate solution with running the FORTRAN compiler and capturing its output written by UltraEdit to the output window and on successful compilation start one more command process to run the just created executable and keep this second command process running while UltraEdit writes the captured output of the compiler to the output window and becomes responsive again for user input is unfortunately not working with UltraEdit for Windows v24.00.0.42 to currently latest v28.10.0.154. It works fine with older versions like v23.20.0.42 or v22.20.0.42.

          The not so good solution with the difference on writing the captured output to an edit window replacing the previously captured text in same edit window instead of the output window works with UltraEdit for Windows v24.00.0.42 to currently latest v28.10.0.154. The disadvantage is that navigating to a line in compiled source code file with an error is not so handy on writing the captured output of the compiler into an edit window instead of the output window. The navigation from one source code line in source code file producing a warning or an error during compilation by using the hotkeys Ctrl+Shift+DOWN ARROW (command Next message) and Ctrl+Shift+UP ARROW (command Previous message) after a not successful compilation is extremely helpful for programmers.

          I suggest for the second user tool to run the compiled executable to use as command line "%n.exe" with the output option Show DOS box checked while the output option Capture output is not checked which makes it possible to input strings if the compiled executable prompts the user for input. But the compiled executable is nevertheless started in this case via cmd.exe started by UltraEdit with option /c and for that reason the Windows command processor closes itself after the compiled executable terminated itself which results in closing also the console window.

          The second tool to run the compiled executable can be configured as follows to see a console window and keep this console window opened even after the compiled executable terminated itself.

          Tab Command

          Menu item name: Run compiled EXE
          Command line: start "Test %n" %ystemRoot%\System32\cmd.exe /D /K "%n.exe"
          Working directory: %p
          Toolbar bitmap/icon file: full qualified file name of an image file with the icon for this user tool

          Tab Options

          Program type: DOS program selected
          Save active file: not checked
          Save all files first: not checked

          Tab Output

          Command output: Append to existing selected
          Show DOS box: not checked
          Capture output: not checked
          Clear output before run: not checked
          Replace selected text with: No replace selected
          Handle output as: ANSI selected

          So what happens on running this user tool with active file having the file name Fortran Test?

          UltraEdit starts in the background the Windows command processor with following command line:

          cmd.exe /c start "Test Fortran Test" %Systemroot%\System32\cmd.exe /D /K "Fortran Test.exe"

          The started cmd.exe interprets the command line after option /c according to the rules described by the help of the Windows command processor output on running cmd /? in a command prompt window. The rules are hard to understand for a beginner in a using the Windows command processor. Many programmers fail to pass a command line correct to the Windows command processor because of not understanding the complex rules applied by cmd.exe on the argument strings after option /c (run and close) or option /k (run and keep running).

          The first cmd.exe instance started by UltraEdit in background without a visible console window first processes the command line and replaces %Systemroot% by C:\Windows. There is nothing more to do and so the command line to execute now by cmd.exe is:

          start "Test Fortran Test" C:\Windows\System32\cmd.exe /D /K "Fortran Test.exe"

          So first cmd.exe executes its internal command start which means the Windows kernel library function CreateProcess is used to start another executable. The other executable to start is in this case C:\Windows\System32\cmd.exe which means one more command process is started by the already running cmd.exe. The usage of command start results in calling the function CreateProcess with a STARTUPINFO structure which contains the information for CreateProcess that a console window should be opened for this executable. That is the reason why now a console window is visible for the second cmd.exe started by the first cmd.exe which was started by UltraEdit without opening a console window. The lpTitle (long pointer to title string) is also used by first cmd.exe and points to the string "Test Fortran Test" which is set by CreateProcess as title for the console window.

          Many Windows users think that cmd.exe opens a console window on being executed, for example on double clicking on a file with extension .bat or .cmd. But that is not true. cmd.exe on being start opens never for itself a console window. That is always the task of the process which starts cmd.exe using CreateProcess. That means that explorer.exe is responsible for showing a console window on double clicking on a batch file which is also the reason why every user can configure multiple different options for each console application started by the Windows File Explorer which most Windows users are not aware of at all. The output option Show DOS box in user/project tool configuration of UltraEdit controls if UltraEdit should start cmd.exe with using CreateProcess without or with opening also a console window by CreateProcess.

          The start of the second command process with using the full qualified file name C:\Windows\System32\cmd.exe and its arguments also passed to CreateProcess works and for that reason the first cmd.exe started by UltraEdit closes itself now. The close of first cmd.exe instance is recognized by UltraEdit which results in this case without capturing anything in finishing user tool execution and UltraEdit is responsive again for user input.

          The second started cmd.exe processes in the meantime parallel to the closing of first cmd.exe instance its arguments. It detects the option /D resulting in ignoring the AutoRun registry string value much too often misused by programmers and people not knowing how harmful it is to make use of the AutoRun registry string value. Next the second started cmd.exe detects the option /K and for that reason knows that it should keep running after finishing execution of the command line which are all other arguments string after option /K.

          The command line to process now by second started cmd.exe for which a console window is visible as created by CreateProcess according to the data in structure STARTUPINFO defined by the first started cmd.exe is:

          "Fortran Test.exe"

          Well, this is nothing else than the name of an executable to run without any arguments. For that reason the second started cmd.exe runs now this executable using also CreateProcess, but this time with a STARTUPINFO structure with data informing the function CreateProcess that no console window should be opened for this console application and that the standard input, standard output and standard error streams of second started cmd.exe should be used and instead of new streams. That is the reason why everything output by the Fortran executable becomes visible in the console window of second started cmd.exe and why the input made in this console window is passed to the Fortran executable for processing it.

          Finally the started Fortran executable terminates and so the second started cmd.exe could terminate too. But it does not do that because of option /K. It keeps running and waits for the next command line input by the user via keyboard (or pasted from clipboard) to process and execute. For that reason the console window remains also open for still running second cmd.exe giving the user the possibility to see all outputs of the former executed Fortran executable and of course the possibility to enter new commands to execute.
          Best regards from an UC/UE/UES for Windows user from Austria

          11
          Basic UserBasic User
          11

            Sep 10, 2021#5

            I am up to speed Mofi.  Please leave the latest-and-greatest version of the post.  Thank you.