Announcing
version 1.1.2
by
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.
The conventional
call, cd, chcp,
chdir, dpath, echo,
endlocal, exit, extproc,
for, goto, if,
path, prompt, set,
setlocal, shift, ver,
and
verify
commands are supplied built in to the command interpreter; but the
conventional
cls, copy, date,
del, detach, dir,
erase, md, mkdir,
move, pause, rd,
rem, ren, rename,
rmdir, start, time,
type,
and
vol
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
that command dir.
Similarly, one can, for another example, wrap the del program
in a script that automatically prepends the /P option.
Extra built-in commands.
? for reporting the list of built-in commands;
alias and unalias for creating and removing
command aliases (in-memory command scripts);
setenv, unsetenv, and
clearenv for managing the process' environment;
pushd and popd for managing a "stack" of
working directories, and dirstack for displaying it;
cdd for changing drive and directory in one operation;
timer for counting elapsed time;
cancel and quit for aborting command script execution;
gosub and return for subroutines in command scripts;
text for including inline text ("here documents") in a command script;
history for displaying the interactive command history;
eset for editing an environment variable;
libpathstrict for setting and querying the operating
system's strict library path feature;
beginlibapath and endlibpath for
setting and querying the library path prefix and suffix;
and
input for prompting the user for input.
Extra external commands.
atdown for running commands when Presentation Manager is shut down,
beep for making beeps,
brightbg for modifying or reporting the state of the console's
bright background flag,
colour for changing the default console colours,
delay for adding a delay to command scripts,
describe for modifying file descriptions,
echos for displaying text sans a final newline,
free for reporting the amount of free space on a volume,
keylocks for modifying or reporting the state of the console's
keyboard lock bits,
lines for modifying the size of the console buffer,
printenv for reporting the contents of the environment
inherited by external commands,
truename for displaying the fully qualified name of a file,
wpsarc for modifying or reporting the Workplace Shell's
desktop archiving flag,
and
zdir for listing directories in the old DOS
style, with descriptions.
32-bit commands to replace the 16-bit commands supplied with IBM OS/2.
ansi for modifying or reporting the state of the console's
ANSI escape sequence recognition flag,
helpmsg for displaying help message text,
and
label for modifying or reporting a disc volume's label.
Year 2000 compliance.
The date and time commands, and the
$D and $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, date and 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
of the date and time commands themselves is the
year 5879615.
Standard-conformant timezone support.
The date and time commands, and the
$D and $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
desired).
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
works. 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 dir
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 del,
copy, for, more,
move, rename, and type.
Enhancements to the for command.
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
%_DATE% and %_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
example, the date and 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.
The 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
after gosub.
Support for redirection of the standard input and output
of the call command.
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.
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 move, rename, and
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 copy command's
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 PATHEXT environment
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:
set and cd,
if, for, and
gosub control structures.
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.