I have some programs that depend on wildcard expansion to process groups of files. For instance, I wrote a program (COMPILES.COB) that wants all the .COB files to be on the command line. The last time I used the program was when I was on Windows 10 and GnuCOBOL 2. To run the program, I just enter it on the command line like this
COMPILES *.COB
The system gave me some 100+ program names that I could process as individual command line entries.
I am on Windows 11 and GnuCOBOL 3.3.0 (Jun 16 2025 13:11:34) now.
I have tried CMD.EXE and CONHOST.EXE and can not figure out why it quit working when using a program. It does work for commands DIR, COPY and so forth.
I use the ACCEPT and DISPLAY from COMMAND-LINE verbs to get the number of command-line arguments and the individual arguments with no problem. It is just the wildcards that don't work anymore.
Anyone else have this problem?
Michael :-)
If you are interested in compiling and running COMPILES.COB, it is in the attached 7zip file. There are several copybooks needed to compile. Sorry, but I use these copybooks in most of what I write.
The original purpose for the program was to automate recompiling MOST of my programs when updating of the cobc compiler required it.
Hm, does it work if you create a compile_all.cmd that includes this and you double-click it? That would at least ensure the cmd.exe is used in its default setup...
As an alternative you could always start a shell to execute your command (and really: for compilation you want to use a Makefile (that still could all COMPILES), makes everything much easier and allows for parallel execution as well).
... and if you really want you can also use the make filename expansion to do a single call (as a workaround, if needed).
Last edit: Simon Sobisch 2025-06-26
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
MOVE SPACES TO EXEC-COMMAND.
STRING
'DIR ' DELIMITED BY SIZE
'\BASE2' DELIMITED BY SIZE
'\*.COB /B/ON > ' DELIMITED BY SIZE
'\BASE2' DELIMITED BY SIZE
'\DIR_PROGRAMS.TXT' DELIMITED BY SIZE
INTO
EXEC-COMMAND.
CALL ZSYSTEM USING
EXEC-COMMAND
EXEC-RETURN-CODE.
MOVE 'BASE2\CBL_PROGRAMS.TXT' TO DIR-DSN
I open the file that DIR created
The output DIR file looks like this
ZOSPD382.COB
ZOSPD402.COB
ZOSPD421.COB
ZOSPD422.COB
ZOSPD423.COB
ZOSPD424.COB
ZOSPD428.COB
ZOSPD432.COB
I use this technique often
The 2nd line of the string command could be accepted from the environment - delimited by ' '
Probably akin to what you are doing :-)
Ralph
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The maximum length for a string at the Windows command prompt (cmd.exe) is 8191 characters. This limit applies to the command line, individual environment variables, and the total length of all environment variable expansions.
While Windows itself has a larger limit for environment variables (32,767 characters), the Command Prompt will disregard any inherited variables exceeding its 8191-character limit. Older versions of Windows (Windows 2000 or Windows NT 4.0) have a smaller limit of 2047 characters.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I found this on the net. Very disappointing because before windows 10, the wildcard expanded.
So I took Ralph's suggestion and rewrote the program.
This is from the net:
Troubleshooting Wildcard Issues in Windows 11 Command Prompt
If you're facing difficulties using wildcards like * or ? in the Windows 11 Command Prompt
(cmd.exe), it's important to understand how they work in this environment.
Key Points:
Shell Responsibility: In Windows' cmd.exe, the shell itself doesn't typically expand
wildcards before passing arguments to a command. The application you are running
is responsible for interpreting and expanding the wildcards.
Application Support: Some applications natively support wildcard expansion, while
others don't.
Alternative Approaches: If the application you're using doesn't support wildcard
expansion directly, you can explore other methods:
FOR Loops: Utilize FOR loops to iterate through files matching a pattern and
perform actions on them.
dir /b: Use dir /b > list.txt to generate a list of files based on a pattern
and save it to a text file. You can then process this list further.
Michael :-(
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have some programs that depend on wildcard expansion to process groups of files. For instance, I wrote a program (COMPILES.COB) that wants all the .COB files to be on the command line. The last time I used the program was when I was on Windows 10 and GnuCOBOL 2. To run the program, I just enter it on the command line like this
The system gave me some 100+ program names that I could process as individual command line entries.
I am on Windows 11 and GnuCOBOL 3.3.0 (Jun 16 2025 13:11:34) now.
I have tried CMD.EXE and CONHOST.EXE and can not figure out why it quit working when using a program. It does work for commands DIR, COPY and so forth.
I use the ACCEPT and DISPLAY from COMMAND-LINE verbs to get the number of command-line arguments and the individual arguments with no problem. It is just the wildcards that don't work anymore.
Anyone else have this problem?
Michael :-)
If you are interested in compiling and running COMPILES.COB, it is in the attached 7zip file. There are several copybooks needed to compile. Sorry, but I use these copybooks in most of what I write.
The original purpose for the program was to automate recompiling MOST of my programs when updating of the cobc compiler required it.
Hm, does it work if you create a compile_all.cmd that includes this and you double-click it? That would at least ensure the cmd.exe is used in its default setup...
As an alternative you could always start a shell to execute your command (and really: for compilation you want to use a Makefile (that still could all COMPILES), makes everything much easier and allows for parallel execution as well).
... and if you really want you can also use the make filename expansion to do a single call (as a workaround, if needed).
Last edit: Simon Sobisch 2025-06-26
Hey Michael
This is how I do something comparble.
I use the command line
I open the file that DIR created
The output DIR file looks like this
ZOSPD382.COB
ZOSPD402.COB
ZOSPD421.COB
ZOSPD422.COB
ZOSPD423.COB
ZOSPD424.COB
ZOSPD428.COB
ZOSPD432.COB
I use this technique often
The 2nd line of the string command could be accepted from the environment - delimited by ' '
Probably akin to what you are doing :-)
Ralph
Thanks Ralph.
But my question was what changed/happened to wildcard expansion when used with a program on the command-line.
I did several programs that create copy books using similar to your code.
The program creates the text file which is used to make the copy file.
Michael :-)
Most OS's command line have a character limit that will limit you. I know on UNIX and Linux it is a tunable value.
Last edit: Simon Sobisch 2025-06-26
The maximum length for a string at the Windows command prompt (cmd.exe) is 8191 characters. This limit applies to the command line, individual environment variables, and the total length of all environment variable expansions.
While Windows itself has a larger limit for environment variables (32,767 characters), the Command Prompt will disregard any inherited variables exceeding its 8191-character limit. Older versions of Windows (Windows 2000 or Windows NT 4.0) have a smaller limit of 2047 characters.
I found this on the net. Very disappointing because before windows 10, the wildcard expanded.
So I took Ralph's suggestion and rewrote the program.
This is from the net:
Michael :-(
... or:
bash -c 'COMPILES *.COB'
(lettting bash expand the files for you)