Changes to the gcx.cmd file

[Mark Manning]

I would like to suggest the following changes to the gcx.cmd file. These are really simple changes but make it so you can either put the ".cob" part on the gcx line or leave it off. It basically just takes the actual filename and leaves the type part off, creates a variable called "cur_prog" (or I guess you could just make it "prog" or whatever) and then substitutes the "%1" with the "%cur_prog%" variable call, thus changing the name of the file being compiled. Again, this is really simple and I just didn't want to have to always remember to take the ".cob" off of the file to compile. Have fun! :-)

Note : I did take the REM off of the front of the CLS command. If you don't like clearing the screen all of the time - just put the "REM " back in front of the CLS command. Sorry about that! :-)

[Mark Manning]

Oops! I just found out that there are TWO gcx.cmd files. One goes with GC312-BDB-M64-rename-7z-to-exe and one goes with GC312-BDB-rename-7z-to-exe. The one I posted goes to the first one. Here is the gcx.cmd file for the second one. Sorry about that! I thought they were the same - but obviously not! :-)

[Mark Manning]

Also - those are for the WINDOWS version of gnuCobol. Ugh. Again - sorry for not posting this correctly. Just found gnuCobol and trying things out. I REALLY like the display feature to be able to put a form on a window. That helps a lot. :-)

[Arnold Trembley]

Thanks for your posting. I plan to incorporate these changes into future builds.

"gcx.cmd" and "gcmf.cmd" are provided in the MinGW GnuCOBOL downloads as working samples, so it is certainly appropriate for the end-user to make changes for their environment.

Kind regards,

[Mark Manning]

Why - thank you! :-) I usually get "Get lost ya ho'ser!" messages. So I'm just flabbergasted! Thank you again! :-)

[Simon Sobisch]

Just a note about the changes: I suggest to use:

if exist .\%cur_prog%.COB (
   set ext=COB
   goto COMPILE
)
if exist .\%cur_prog%.CBL (
   set ext=CBL
   goto COMPILE
)

and then only have one "COMPILE" label.

Also note -W is actually the old form of-Wextra, you likely want to change it to -Wall.

[Mark Manning]

Oooooo....that looks neat. Let me go try it out!

Ok. I did some reading and it turns uut you can use %_x# to get the extension of the incoming file. BUT - this did not take in to account when NO extension is set to the command. I didn't either! So I had to fix that.

[Mark Manning]

Ok. I just finished the gcx.cmd programs and I've gotten them to do the following:

1. If you pass it a bogus file, it tells you that and then exists (so I tried "abcd.efg") - works
2. If you pass it a filename with either ".cob" or ".cbl" it uses the right name (ie: "abcd.cob" or "abcd.cbl" compiles as that file. - works
3. If you just pass in the filename and NO extension, the program tries to guess which file to use. So if you have "abcd.cob" but only pass in "abcd", the program will GUESS that "abcd.cob" is the right name to use. If you have "abcd.cbl" but only pass in "abcd", the program will GUESS that "abcd.cbl" is the right name to use. If you have both - the "cob" file is what is used. This is consistent with the original script. - works! :-)
4. Also! I revamped the gcx.cmd & gcx64.cmd files to use only one IF-ELSE-THEN statement to handle BOTH the compile AND the error areas.
5. I just remembered I changed the "-W" option to "-Wall" like Simon Sobisch talked about. If this isn't right - you will need to change that.

Note : I have included BOTH the 32bit version and the 64bit version of gcx.cmd. I HAVE RENAMED the gcx.cmd file for 64bit to gcx64.cmd. In this way I can use both of them.

[Arnold Trembley]

Thank you SO much! This makes my job easier.

Kind regards,

[Mark Manning]

Do you need someone to look at/work on your command files? Please let me know. Thanks!

[Alan Honeyman]

I'm just starting out on this adventure. I have installed Arnold's package in C:/GC32M and I have a Cobol source called fred in C:\Cob_Progs. I'm having problems compiling, specifically the format of of the gcxcmd parameter. Could someone please help me out here?

[Arnold Trembley]

The gcx.cmd file (as written or the MSYS2 GC32RC2 compiler), expects to be in the compiler folder, in order to run the set_env.cmd file for compiler environment variables. This is not a good practice, as you should not put your COBOL source code in the same folder as the compiler. The

Look for the following lines in the gcx.cmd file:

REM pause 
rem CALL the "set_env.cmd" script to set GnuCOBOL environment variables
echo call %~dp0\set_env.cmd
call %~dp0\set_env.cmd

And either comment them out or remove them. Then, before compiling, navigate to the folder where the compiler is installed and run set_env.cmd. That will set your GnuCOBOL compiler environment variables. You can also run the set_env.cmd script from any location, as long as it is fully pathed to its location (i.e. c:\Gnucobol\set_env.cmd if the compiler is installed in a folder named C:\GnuCOBOL). It only works if if runs in the parent folder of \bin. Be aware that when the CMD.exe or WT session window is closed, the temporary environment variable settings will be forgotten.

Then navigate to the folder where you COBOL source code resides and run the gcx.cmd file. It expects the name of the COBOL main program, either with no file extension or .cob or .cbl for the file extension. The preferred extension is .cbl. For example, simply type
"gcx FRED" in your CMD.EXE or Windows Terminal CMD window. Check for any syntax errors that cause the compile or link to fail. If the compile & link are successful, then you can execute the program by typing its name (i.e. fred) on the command line.

You can modify the gcx.cmd script for your preferred compile options.

I hope that helps!

Kind regards,

[Simon Sobisch]

The gcx.cmd file (as written or the MSYS2 GC32RC2 compiler), expects to be in the compiler folder, in order to run the set_env.cmd file for compiler environment variables.

Not completely right - the gcx.cmd file expects to be next to set_env.cmd (which expects to be in the compiler folder) - but this explicit allows you to call it from everywhere, for example from the COBOL source folder.
The lines you've mentioned are necessary for that and should not be removed as long as the gcx.cmd is called from the compiler folder.

[Alan Honeyman]

Arnold, thanks for the response. As I indicated, my cobol program is not in the folder where the compiler sits (C:/GC32M) but is in C:/Cob_Progs and is called fred.cob. So, I navigate to c:/GC32M and type:

gcx.cmd c:/Cob_Progs/fred.cob

and it responds:

COBOL source code file "fred" NOT FOUND in this directory.
NO compilation will occur.

Does it not like me pointing to where the source code is? Is it assuming it is in the current directory?

[Arnold Trembley]

In the C:\GC32M folder you should run the "set_env.cmd" script to set the compiler up.

Then navigate to the C:\Cob_Progs folder, where you can run the "gcx fred" script. "gcx.cmd" expects the cobol source file to be in the local folder, and using a full path won't work because of the local variables cannot extract the separate filename and extension name for the extension name edits:

set cur_prog=%~n1
set cur_ext=%~x1
rem
rem What happens if no extension is given?
rem
if [%cur_ext%] == [] (
  rem echo.
  rem echo.========================================================================
  rem echo There is NO extension - Figuring it out
  if exist .\%cur_prog%.cob set cur_ext=.cob
  if exist .\%cur_prog%.cbl set cur_ext=.cbl
  rem echo.========================================================================
  rem echo.
)

The extension name can be left out of the gcx command, and gcx will check for fred.cob or fred.cbl. If both are present, fred.cbl will be selected. But you can also use either file extension in the gcx command (i.e. gcx fred.cob or gcx fred.cbl).

If you want to always have gcx.cmd call the set_env.cmd script, then you must make it fully pathed to the compiler folder. You could also CD to that folder, call set_env.cmd, and CD back to your original folder. You could also use the PUSHD and POPD batch commands.

Hope that helps!

[Simon Sobisch]

... no again - the gcx,cmd should be adjusted, not for caling set_env.cmd but possibly for checking its parameters.

%~n1 drops the path - which likely is exactly the right thing for using %cur_prog% in several places - but the compile should use the full path and not expect to be called where the source is.

Also see https://ss64.com/nt/syntax-args.html

[Arnold Trembley]

I'm not sure exactly how you do that, because for me the biggest problem is switching between different GC compiler folders and my COBOL source folder. I usually have more than six different GC compilers installed on my main desktop.

I see the problem now. I need to remove the copy of gcx.cmd that I have in my COBOL source folder, since it has no way to know which set_env.cmd script to call, and obviously breaks this approach. Then you can always start in a compiler folder to run set_env FIRST, then switch to the COBOL source folder and always pick up the gcx.cmd from the starting compiler folder.

As to the other problem, %~n1 is the filename, but without the path, and of course %~x1 being an extension can never have a path. So, how to add back (pre-pend) the path to
%cur_prog%%cur_ext% ?

http://steve-jansen.github.io/guides/windows-batch-scripting/part-2-variables.html

I suppose %~dp1 would be the full path to the gcx.cmd first argument (cobol source file), but if we allow it to sometimes not have a file extension, then we need to know both when and how to add it back. Is it possible to SET %~x1 after we determine that it's blank?

Obviously, there is still room for improvement in cmd scripts.

Kind regards,

[Alan Honeyman]

Ok, I run set_env.cmd and then cd to cob_progs, type gcx fred and it says:

"gcx" is not recognized.....

[Simon Sobisch]

If you don't have a need to use gcx.cmd: just call cobc -x fullpathtosource.cob.

[Alan Honeyman]

OK, that worked. Thanks Simon.

[Alan Honeyman]

The exe file was not put in the same folder and the source, it was put in the gc32m folder. Something to avoid I would have thought. Can I define where the exe file should be deposited?

[Simon Sobisch]

-o fullpath.exe, defaults to "first file name specified as source + .exe/.dll "(depending on use of -x) in the current working directory.

cobc --help should be useful.

[Alan Honeyman]

Excellent! Thank you.