FreeCOM Alias Expansion: Arguments, Shadowing, Persistence, and Safe Use

FreeDOS FreeCOM includes an internal ALIAS command that expands a command name into another command string. It can shorten repetitive commands, provide a preferred default option, or create a local workflow shortcut. It is shell behavior, not an executable installed separately and not a global DOS API. The exact semantics belong to the FreeCOM version and build configuration, so a script that depends on aliases should state which command interpreter runs it.

An alias is not the same thing as DOSKEY-style interactive history or keyboard editing. FreeCOM’s command-line editing features are one part of the shell; alias expansion is a separate command-processing feature. Keeping those concepts separate makes it easier to diagnose why a typed command changes before execution or why an alias works in one shell but not another.

Define, inspect, and remove aliases

The FreeDOS help reference documents ALIAS with no arguments as listing aliases, ALIAS name=string as assigning a replacement, and ALIAS name= as removing an alias. For example:

ALIAS ll=DIR /W
ALIAS
ll C:\FREEDOS
ALIAS ll=

After ll is entered, FreeCOM expands the alias name to the stored string and appends the arguments supplied to the original command. In this example, the directory argument is passed to the expanded DIR /W command. This makes simple aliases convenient, but it also means the replacement must be designed for the actual argument shape users will append.

Do not assume a POSIX shell’s quoting, function, variable, or recursive-expansion rules. FreeCOM is a DOS command processor with its own parser and command-line buffer. The official command help describes the basic replacement behavior but does not define every parsing edge case for all versions. Test quoting, redirection, pipes, metacharacters, and batch-file use on the exact FreeCOM build before relying on them.

Aliases can shadow ordinary commands

An alias can use a familiar command name such as DIR, which changes how that command behaves in the current interpreter. FreeDOS’s help examples intentionally demonstrate an alias that supplies /W to DIR. That convenience is also a source of surprises: a user may type a standard command and receive a modified invocation or a command not found after an alias has been removed.

FreeCOM documents an asterisk prefix to suppress alias expansion for a command line, such as *name arguments. This escape is useful for diagnosing a shadowed command or reaching a literal command name, but validate it in the installed shell and do not assume other DOS shells implement it. The suppression rule is a FreeCOM feature, not standard batch-language syntax.

Before creating an alias with the name of an internal command, examine the existing list and decide whether every user of that shell should inherit the change. Aliases can affect interactive use and can make troubleshooting harder when startup scripts set them silently. A clean test profile with a minimal AUTOEXEC file helps isolate the shell’s built-in command from the alias.

Persistence and memory ownership

Aliases are stored in FreeCOM’s context segment according to the help reference. Their lifetime is therefore tied to the command interpreter instance and its available shell memory, not to a system-wide registry. To make an alias persistent across shell startups, the documented approach is to place its definition in AUTOEXEC.BAT or the FreeDOS startup script in use. A child command processor may have its own context and may not share every alias with its parent.

FreeCOM’s command-line options can adjust the environment size, but environment storage and alias context storage are distinct concerns. Do not assume that increasing COMMAND /E: directly increases alias capacity. Review the installed shell’s help and source for the specific version, and monitor available conventional memory when adding many aliases or other resident utilities.

Persistence also introduces a deployment concern: if an alias definition is malformed or shadows a recovery command, the shell can start in a confusing state. Keep a backup of the startup file, make one change at a time, and retain a boot menu option that starts a minimal shell profile. Never test a destructive alias on a directory or disk containing the only copy of important files.

Design aliases that preserve intent

Use aliases for transparent defaults with low consequence, such as a directory display option or a short path to a known utility. Avoid aliases that hide destructive flags, silently change drives, delete files, format media, or invoke a command with a different security or data-loss profile. The command line should remain understandable to the operator reading it later.

Document the expansion plainly next to its startup definition:

REM Local interactive convenience; does not replace the DIR executable.
ALIAS ll=DIR /W

This comment is advisory; FreeCOM processes the ALIAS command, while REM is interpreted by the shell’s batch parser. Confirm that the comment and alias are supported by the exact command interpreter. For a shared deployment, list aliases in a dedicated startup section and include a command to display or remove each one.

If a workflow must be reproducible independent of a user’s shell, put the operation in a batch file or invoke the explicit command and options instead of depending on an ambient alias. An alias is mutable interactive state. A batch file that assumes copy or dir has a particular alias can behave differently on another installation or after a user starts a secondary shell.

Troubleshooting unexpected expansion

If a command behaves differently from its executable’s help, list aliases first. Look for names matching built-in commands and external utilities. Temporarily remove one alias or prefix the command with the documented suppression character, then repeat the same arguments. Capture the FreeCOM version, startup files, current alias list, current directory, environment, and exact command line.

If an alias works interactively but not in a batch, verify that the batch is being executed by FreeCOM and not another command processor. Check whether the alias was defined in the same interpreter instance and whether startup ordering places the definition before its use. A correct executable search path cannot repair a command line that was already expanded differently.

If aliases disappear after starting a child shell, compare the parent and child alias lists rather than assuming shared state. If shell startup fails after editing AUTOEXEC, boot using the alternate profile or a recovery medium and restore the backup. Do not keep appending definitions until the root cause is understood; duplicate aliases or order-dependent startup scripts make later diagnosis harder.

Acceptance checks

On the target FreeDOS release, verify that bare ALIAS lists entries, assignment creates the intended replacement, appended arguments reach the command, deletion removes the definition, and the documented prefix suppresses expansion. Repeat in interactive mode and from the intended batch startup path. Test a benign alias shadowing a built-in and recover using the literal-expansion escape or a minimal boot profile.

Review the stored strings for metacharacters, redirection, pipes, and destructive commands. Confirm the exact shell build has alias support enabled. Reboot and verify persistence only when intended; start a second shell to check instance behavior. Keep an explicit list of active aliases with the configuration so operators can reproduce and reverse the setup.

FreeCOM aliases are useful because they are simple and local to the command processor. Treat their expansion as mutable shell state, keep the underlying command visible, test the exact parser, and avoid using aliases as an invisible dependency for critical batch automation.

Related:

Sources: