The 32-bit Command Interpreter

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 the The OS/2 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-prompt style tools without duplicating all of the effort of command-line parsing, variable expansion, built in commands, and command script execution.

• Features
• The CMD API
• Non-English Versions

FEATURES

The 32-bit CMD has all of the features that one expects as standard in an OS/2 command interpreter, including:

• the ability to run scripts in the CMD language (a.k.a. "batch files");
• the ability to run scripts in the REXX language;
• no 8.3 limitations on filenames;
• the ability to have multiple commands on a single line;
• the ability to have command pipelines;
• support for the /? option in all commands; and
• on-line documentation supplied in IBM's standard book format.

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, mkdir, move, pause, rem, 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; 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 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 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.

• "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.

THE CMD API

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:

• redirection of the input and output of commands,
• environment variable substitution in command lines,
• multiple commands on one line,
• full on-line help,
• a uniform command option syntax across most commands,
• full support for the standard built-in commands such as set and cd,
• support for command scripts, and
• support for the 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.

NON-ENGLISH VERSIONS

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.