Jonathan de Boyne Pollard
The 32-bit CMD for OS/2 is a native OS/2 command interpreter. It is designed
to be highly compatible with the 16-bit
CMD.EXE supplied with
OS/2 by IBM, providing the same range of commands and the ability to execute
the same command scripts, whilst on the other hand taking full advantage of
32-bit OS/2 and leaving behind several of the long-standing limitations and
quirks IBM's command interpreter has inherited, sometimes for no reason,
from MS/PC/DR-DOS (and even from CP/M in some cases).
Some useful accompaniments to the 32-bit CMD are utility suites such as JdeBP's Command Line Utilities, and The Graham Utilities for OS/2.
The CMD API is supplied for the benefit of third party developers who wish to provide alternate user interfaces to the command interpreter, or who wish to write interactive command-line interpreter style tools without duplicating all of the effort of command-line parsing, variable expansion, built in commands, and command script execution.
For full information, see the on-line documentation.
The 32-bit CMD has all of the features that one expects as standard in an OS/2 command interpreter, including:
/?option in all commands; and
In addition, the 32-bit CMD provides several extensions to and improvements on the features of IBM's 16-bit CMD, such as:
Pure 32-bit code. The 32-bit CMD contains no 16-bit code whatsoever, and uses no 16-bit OS/2 subsystems. (It uses the 32-bit Unicode Console API for OS/2.)
Fewer "hard-wired" commands. The 32-bit CMD aims to have the minimum number of built in commands that are necessary.
commands are supplied built in to the command interpreter; but the
commands, that are built in to other command interpreters, are in fact
supplied as external commands.
This means that they can be replaced with other, equivalent, programs
should that be desired. If one doesn't like the way that the
dir command operates, for example, one can replace it with a
substitute of one's own choosing, such as a third party "better DIR"
command (or even the supplied
zdir command), and call
Similarly, one can, for another example, wrap the
in a script that automatically prepends the
Extra built-in commands.
?for reporting the list of built-in commands;
unaliasfor creating and removing command aliases (in-memory command scripts);
clearenvfor managing the process' environment;
popdfor managing a "stack" of working directories, and
dirstackfor displaying it;
cddfor changing drive and directory in one operation;
timerfor counting elapsed time;
quitfor aborting command script execution;
returnfor subroutines in command scripts;
textfor including inline text ("here documents") in a command script;
historyfor displaying the interactive command history;
esetfor editing an environment variable;
libpathstrictfor setting and querying the operating system's strict library path feature;
endlibpathfor setting and querying the library path prefix and suffix; and
inputfor prompting the user for input.
Extra external commands.
atdownfor running commands when Presentation Manager is shut down,
beepfor making beeps,
brightbgfor modifying or reporting the state of the console's bright background flag,
colourfor changing the default console colours,
delayfor adding a delay to command scripts,
describefor modifying file descriptions,
echosfor displaying text sans a final newline,
freefor reporting the amount of free space on a volume,
keylocksfor modifying or reporting the state of the console's keyboard lock bits,
linesfor modifying the size of the console buffer,
printenvfor reporting the contents of the environment inherited by external commands,
truenamefor displaying the fully qualified name of a file,
wpsarcfor modifying or reporting the Workplace Shell's desktop archiving flag, and
zdirfor listing directories in the old DOS style, with descriptions.
32-bit commands to replace the 16-bit commands supplied with IBM OS/2.
ansifor modifying or reporting the state of the console's ANSI escape sequence recognition flag,
helpmsgfor displaying help message text, and
labelfor modifying or reporting a disc volume's label.
Year 2000 compliance.
time commands, and the
$T sequences in the command prompt,
default to using the international standard
ISO 8601 formats
for displaying dates and times (although the country-specific form is
still available, if required) that uses 4 digit year numbers.
Year 2100 compliance.
On OS/2 Warp 4,
time can both operate
well beyond the year 2000, and even well beyond the year 2038, and in
fact up to the year 2079, which is the limit for OS/2 Warp 4's real-time
clock. If a future version of 32-bit OS/2 extends this limit, the limit
time commands themselves is the
Standard-conformant timezone support.
time commands, and the
$T sequences in the command prompt,
understand the timezone information supplied in the TZ environment
variable, using the standard POSIX (ISO/IEC 9445-1:1990) syntax, and
can operate in any timezone with daylight savings time changes
happening automatically without manual user intervention. The
dir command by default displays file timestamps relative
to the local timezone (although timestamps can be displayed in UTC if
No more CP/M Think. Many commands in other command interpreters still contain old CP/M paradigms for file handling. But even MS-DOS version 2.0 didn't actually treat CTRL-Z (ASCII 26) in a file as an end-of-file marker. The behaviour had to be implemented in the commands themselves, on top of the native MS-DOS version 2.0 behaviour.
The 32-bit CMD finally brings this nonsense to an end. The commands
supplied with the 32-bit CMD, such as
type, aren't burdened
with this CP/M silliness. They use the native 32-bit OS/2 behaviour when
it comes to the contents of files. ASCII character 26 in a file is treated
the same as any other character is, because that's how OS/2 actually
copy won't append extra CTRL-Z characters to the ends
of files when copying them, either. When
copy copies files,
they really will be exact copies.
No more arbitrary 16-bit limits. Most commands are limited only by the available virtual memory.
For example, the
dir command in IBM's CMD refuses to sort a
directory listing containing more than 2073 files (which is as many file
information structures as will fit into 64KiB). The
command in JP Software's 4OS2 fails to sort directories larger than a more
respectable 20,000 files. But the
dir command supplied with
the 32-bit CMD was able, in testing, to sort a directory listing of
100,000 files, and even that didn't reach its limit. (I just ran out of
enthusiasm to go any higher. (-:)
No more arbitrary 16-bit limits. The 32-bit CMD fully supports having have more than 64KiB of environment variables. (IBM OS/2 itself has some trouble with this, however.)
No more arbitrary 16-bit limits. The length of a single line in a command script is limited only by the amount of free virtual memory in the command interpreter process.
Standard options across many commands.
For example: The /S (operate recursively on an entire directory tree) and
/A (select files and directories to process by their attributes) options
are supported by many commands, including
Enhancements to the
Yes, you spotted it. The
for command does indeed support
recursion into a subdirectory tree. It also supports long names for the
iteration variable and reading the values of the iteration variable
from files or from its standard input.
"implicit" environment variables.
For example: If no environment variables by the names exist, the sequences
%_TIME% are converted, by
environment variable expansion, into the current date and time.
Support for some "unofficial" features of IBM's CMD.
But, unlike in IBM's CMD, in the 32-bit CMD they actually work. For
time commands both support
the /N option (which is documented in IBM's on-line help, but doesn't
actually work in IBM's CMD).
No support for the traditional command interpreter
stupidies that are not actually documented.
For example, the
copy command in IBM's CMD has the
traditional, but nonetheless undocumented, limitation of refusing, for no
reason, to copy zero-length files. The
copy command(s) in
the 32-bit CMD will happily copy zero-length files.
Support for subroutines in command scripts.
gosub command can be used to call a label in a command
script as a subroutine, which then executes until a corresponding
return command is encountered to return to the next command
Support for redirection of the standard input and output
More logical support for nested command scripts. If one command script invokes another command script, the second script is automatically nested within the first, rather than causing the first to terminate. This means that one doesn't need to know whether an external command happens to be a command script or a real executable before using it within another command script.
Two alternative versions of the
copy command itself is a simple command script that
invokes one of two commands,
according to one's taste.
COPYSTD.EXE concentrates on the way that the
copy command is most often used in practice. Its command
syntax matches that of
del, without any unexpected surprises or quirks. However,
this doesn't support the less used features of the traditional
copy command, such as file concatenation.
COPYPLUS.EXE supports all of the features of the traditional
copy command, and even enhances them with things like the
ability to perform concentenation in multiple subdirectories. But it does
so at the expense of having the traditional
idiosyncratic and quirky syntax that is both difficult to remember and
inconsistent with the syntax of other commands.
Even more flexible external command execution.
It is a little known fact that IBM's CMD can execute any file as if it
were a program, irrespective of ".EXE" or ".COM" extension. The 32-bit
CMD does this and more. It supports the
variable, allowing one to control what extensions are treated as those of
executable commands when searching
PATH, and in what order;
and it supports controlling when the current directory is searched,
allowing one to prevent command spoofing.
Reduced memory requirements for the bundled external commands. All common code used by the external commands supplied with the command interpreter resides in shared DLLs, which OS/2 will only need to load one instance of into memory. Also, if the external command is invoked from the command interpreter, the DLLs will already have been loaded into memory by the command interpreter itself, reducing the time taken for OS/2 to load and execute the command.
Alternative front ends. The command interpreter comes with three different front ends, that provide three different user interfaces:
cmd employs a simple "glass TTY" interface, using
the input editing features supplied by the operating system itself.
It is suitable for non-interactive use or where its input is being
supplied via a pipe.
textcmd employs the
32-bit Unicode Console API for OS/2
to provide a textual user interface suitable for interactive work
in a console. It supports a history list, whose behaviour and content
is modifiable via the
history command; and command line
editing, with filename completion, command line recall using prefix
matching, and customisable insert/overwrite behaviour.
pmcmd provides a simple graphical user interface,
with command line history being provided by a "combo box" control.
The 32-bit CMD provides an application programming interface for software developers to make use of. As the REXX interpreter can be linked into OS/2 applications to make them scriptable using the REXX language, so too can the script file interpreter of CMD be linked into OS/2 applications to make them scriptable using the CMD language.
Programs that use the API gain all of the features of the "regular" command interpreter, such as:
In addition, developers are provided with mechanisms to enable, disable, and rename the standard built-in commands, and to add their own built-in commands.
The messages displayed by the command interpreter and the external commands supplied with it are taken from message files rather than hard-coded into the programs themselves, which is of course the standard way that 32-bit OS/2 applications should work.
Some of the messages are taken from OS/2's own system files, and so those messages will automatically be rendered in the correct language on non-English versions of OS/2 without further effort.
Translating the remaining messages into another language is simply a matter of substituting new CMD.MSG and CMDH.MSG files at runtime. Volunteers for translating the messages are welcome to contact the author.