Skip to content
FreeDOSDeep Dive Published Updated 7 min readViews unavailable

FreeDOS SET: Environment Variables, Shell Boundaries, and Inherited State

Manage FreeDOS environment variables with SET while separating CONFIG.SYS initialization, shell state, child processes, expansion behavior, and capacity limits.

In FreeDOS, SET changes the environment used by the DOS kernel during startup or by the command shell after startup. The two contexts look similar in a configuration file, but they are not the same command processor. A reliable setup distinguishes the kernel’s CONFIG.SYS environment assignments from FreeCOM’s interactive and batch SET command, and treats each shell’s environment as process state rather than as one global variable table shared by every program.

Environment variables carry conventions such as PATH, COMSPEC, DOSDIR, and application-specific settings. They are plain name/value strings. They do not reserve a drive, validate a pathname, configure a device by themselves, or force a program to honor them. The consumer defines the meaning. A variable that is misspelled, truncated by a small environment block, or expanded in the wrong parsing context can turn a boot script into a hard-to-diagnose failure.

Two SET commands run at different times

FreeDOS documents a SET directive for CONFIG.SYS / FDCONFIG.SYS and a separate internal SET command provided by COMMAND.COM / FreeCOM. The configuration directive is processed by the kernel during startup and does not accept all the shell command’s switches. The shell command can display, add, change, or remove variables during an interactive session or a batch file.

A startup assignment can establish values needed by later boot commands. For example, the kernel configuration can define DOSDIR, while AUTOEXEC.BAT can add a tool directory to PATH. Put each assignment in the correct stage. A variable required by a driver during configuration processing cannot be assumed to exist because a later batch file will set it; conversely, a shell-only display switch such as SET /P is not a configuration directive.

FreeDOS documentation describes the environment as part of COMMAND.COM / FreeCOM operation. Restarting the machine clears the interactive changes unless startup scripts set them again. This is why a temporary diagnostic assignment belongs at the prompt, while a persistent machine policy belongs in the selected boot configuration or startup batch file. Before editing either one, identify whether the active profile is CONFIG.SYS, FDCONFIG.SYS, AUTOEXEC.BAT, or FDAUTO.BAT.

Inspect before modifying

Run SET without parameters to list current name/value pairs, or request one variable by name. Do this before changing a broken PATH, TEMP, or COMSPEC value. Keep a copy of the current output in the maintenance record, especially when diagnosing a shell started from another shell or a batch file that may alter variables.

The basic forms are:

set
set PATH
set PATH=C:\FREEDOS\BIN;C:\TOOLS
set TEMP=

The precise separator convention for PATH is the semicolon. A missing delimiter can create a single invalid directory string. Removing a variable with an empty assignment is different from assigning a path that happens to end in a backslash. Check the exact value after editing and test command lookup using a known harmless executable.

By default, FreeDOS SET uppercases variable names for compatibility. Its /C option preserves the case that is supplied. The command help also documents /U to uppercase a value, /P to prompt for a value, /I to show environment-segment size, and /E to set a variable to the first line of output from a command. These are FreeCOM command features, not portable syntax to assume in arbitrary DOS shells or in CONFIG.SYS.

Use /E and /P deliberately. A prompt can return an empty value, in which case the documented command removes the variable. A command used with /E may return empty or unexpected output; validate the value before using it in a destructive command. Do not place secrets in environment variables under the assumption that they are protected: DOS environments are not an access-control boundary.

Expansion happens in the command processor

FreeDOS documentation explains that environment values are expanded by the shell before the resulting command line is further parsed. That ordering matters when values contain quote characters, separators, redirection symbols, or command syntax. A variable containing an odd number of quotes can require a closing quote later in the command line; a variable name that shares a prefix with a batch parameter can also interact with percent expansion.

Avoid storing arbitrary untrusted text in a variable and then expanding it into a command that deletes, formats, copies, or overwrites data. DOS command interpreters do not provide modern structured argument passing or a universal escaping function. Keep variable values simple, quote paths where the shell supports it, and test the fully expanded command on a disposable directory. For complex data, use a program that reads a file or standard input rather than constructing an executable command line from free-form text.

Batch scripts need additional care because percent signs also denote positional parameters and batch substitutions. FreeCOM’s parsing rules and switches should be checked in its documentation for the exact behavior required. Do not copy a quoting pattern from a modern PowerShell or POSIX shell and expect DOS parsing to be equivalent. A short test batch file that prints the expanded value with ECHO is safer than discovering expansion behavior in a privileged or destructive line.

Environment capacity and child programs

Each command processor has a finite environment block. FreeDOS’s COMMAND.COM documentation describes /E:nnnnn for setting the initial environment size when starting a shell. A SET operation can fail or exhaust the available block if the shell has too little reserved space. The SET /I diagnostic can help inspect the environment segment size, and the separate FreeDOS troubleshooting guidance for environment-space errors should be used before removing variables arbitrarily.

A child program receives environment state made available by its parent process when DOS launches it. That does not make environment variables a kernel-wide live database: a value changed by a child should not be assumed to rewrite the already-running parent shell. If a program needs to communicate a result back, use its documented exit code, a file, or another explicit mechanism. This boundary explains why running an external utility to “set” a variable is not equivalent to typing the internal SET command in the shell that must use the new value.

When starting a secondary command processor, choose the shell path and environment size intentionally. A nested shell can inherit or receive a bounded environment according to its launch configuration, consume additional conventional memory, and then disappear when exited. Test that COMSPEC resolves to the expected shell and that environment sizing leaves room for drivers, resident programs, and the application’s own memory requirements. An oversized environment is not free; it competes with conventional memory in a real-mode system.

A controlled configuration workflow

For a temporary test, change the value in the current shell, inspect it, run a harmless lookup, and then remove or restore it:

set TOOLROOT=C:\TOOLS
set TOOLROOT
set PATH=C:\FREEDOS\BIN;%TOOLROOT%
set PATH

The example demonstrates intent, not universal quoting behavior for every shell build. First verify how the installed FreeCOM expands variables and whether an existing value must be retained. Capture the original PATH before replacing it. Avoid appending repeatedly in a startup file; each reboot could grow the value until the environment block is exhausted.

For persistent configuration, edit one startup location at a time, keep a backup, and boot the intended profile. Confirm the final variables from the interactive shell after startup, then run the exact program that consumes them. If the change breaks shell startup, use the boot menu or a recovery disk to restore the prior configuration. Do not let a successful SET return be the only acceptance test.

Operational checks

Before declaring a variable change complete, record its source file or interactive command, spelling and case, final expanded value, and consumer. Check for duplicate assignments in both CONFIG.SYS and AUTOEXEC.BAT, particularly when multiple boot configurations are present. Confirm that the variable fits the shell’s environment capacity and survives exactly the process boundary intended.

FreeDOS SET is simple syntax over bounded process state. Reliability comes from putting each assignment in the correct initialization stage, checking expansion before execution, preserving enough environment space, and not treating values as secure or globally mutable state.

Related:

Sources:

Comments