Skip to content
FreeDOSDeep Dive Published Updated 7 min readViews unavailable

FreeDOS SORT: Stream Ordering, Locale Rules, and Bounded Input

Use FreeDOS SORT with explicit input, key columns, NLS, and ASCII ordering, while accounting for memory limits and repeatable output.

FreeDOS SORT orders text lines from a named file or from standard input. It can reverse the order, begin comparison at a selected column, and choose between locale-aware ordering and ASCII ordering. Those options make it useful for directory listings, small manifests, and human-readable inventories. They do not make it a general-purpose database sorter: records are line-oriented, the implementation has documented memory and input limits, and the exact comparison rules should be tested under the active country configuration.

The command reference documents this basic grammar:

SORT [/R] [/N] [/+num] [/A] [filename]
TYPE C:\REPORT\FILES.TXT | SORT /A
SORT /+21 C:\REPORT\RECORDS.TXT > C:\REPORT\SORTED.TXT

Without a filename, SORT reads standard input. It writes sorted output rather than modifying the named input file. This is a useful safety property, but it is not a backup strategy: redirection can still overwrite an existing destination. Use a distinct output name, inspect it, and only then promote it using a separately planned operation.

Decide what the comparison key means

By default, the entire line is used as the key, beginning at column 1. /+num begins comparison at a specified one-based column. That is useful for a fixed-width text record when the leading columns contain a sequence number or prefix that should not determine ordering. It is not a parser: SORT does not know where fields begin, whether quotes protect a delimiter, or whether a column is a number.

0002  ALPHA   10
0001  BRAVO    2
0003  ALPHA    3

Sorting this fixture from column 7 ignores the initial numeric identifier and compares the text beginning with the name field. It will still compare characters, not understand that the trailing value 2 should come before 10 numerically. Test the column offset with a tiny fixture containing known ties and near-ties before processing real data.

/R requests reverse order. It reverses the ordering result; it does not mean “sort by a descending numeric field.” If a record contains numbers as strings, lexical ordering can differ from numeric ordering. For example, character comparison can place 100 before 20 because the first characters are compared, not the represented integer values. Normalize data or use a tool that understands the data schema when the distinction matters.

Locale, NLS, and ASCII are different policies

The FreeDOS reference says /A selects ASCII order instead of COUNTRY sort order, while /N enables national-language support. SORT also supports NLS according to the same page. These settings make output dependent on the environment if locale behavior is selected. A file sorted on two FreeDOS installations with different country/code-page state should not automatically be expected to produce byte-identical order.

Choose /A when an ASCII-oriented ordering is explicitly required by the consuming process. Choose the normal COUNTRY-aware behavior when a user-facing order should follow the configured national collation rules. Do not call either one universally “correct”: a manifest consumed by a script may need reproducible byte order, while a display list may be expected to follow locale conventions. Record the setting, code page, and command switches with a reproducible test result.

/N is documented as enabling NLS, but the help page does not fully specify every interaction among /N, /A, country tables, extended characters, and each installed build. Avoid claiming that the output is Unicode-aware. DOS files are interpreted through the active DOS environment and supported character tables. If the dataset includes accented or extended characters, create a representative fixture and compare the result under the intended COUNTRY/CODEPAGE configuration. Preserve the fixture bytes so later testing can distinguish a collation change from an encoding change.

Keep the input method explicit

A filename argument is easiest to audit because the input path is visible in the command. Standard input is useful for a pipeline, but pipeline behavior involves both the shell and SORT. FreeCOM documents that DOS pipes are simulated with temporary files rather than concurrent processes. Therefore, a pipeline is not a modern streaming contract with arbitrary-size buffered flow; intermediate files and available disk space can matter.

SORT /A C:\REPORT\NAMES.TXT > C:\REPORT\NAMES.ASC
IF ERRORLEVEL 1 GOTO SORT_FAILED
GOTO SORT_DONE

:SORT_FAILED
ECHO Review SORT input, output path, and memory limits.
:SORT_DONE

The sample is only a control-flow sketch: confirm the specific SORT build’s documented exit status before making it a deployment gate. A utility’s successful-looking output is not proof that every expected line was accepted. The help page documents maximum record length and record count for the documented version, plus a conventional-memory-only implementation that can run out of memory before reaching the nominal maximum. Keep operational data comfortably below those limits and test a boundary-sized fixture on the target machine.

The help page also notes that a paginated DIR feeding SORT can appear to pause and show nothing until the user answers the pause prompts. Avoid making an interactive producer the input to an unattended sort. Prefer a previously captured plain-text file with known line endings and a known record count. If the source is a command listing, capture it first, verify its completeness, then sort the captured file.

Verify output instead of trusting visual order

Create a test file with: deliberately unsorted lines; two lines sharing the sort key; records with differing case; a value such as 2 and 10; leading spaces; and at least one extended character if relevant. Run default ordering, /R, /+num, /A, and /N independently. Inspect the entire output and establish what happens for ties; do not rely on an undocumented stable-sort guarantee.

For a production inventory, preserve the original input and count its lines before and after. A sorted output should contain the same records, except for any newline-normalization behavior verified on that exact implementation. Compare input/output as multisets with a trusted external checker when possible; FreeDOS SORT itself does not provide an integrity checksum. If the list is safety-critical, image or copy the source first and store the output under a new path.

An output that looks ordered on screen can still omit data if the producer was paginated, the pipeline stopped early, or SORT exhausted available conventional memory. Validate record count independently. When a source command emits status messages on standard output, those messages are records too; capture the desired data with a command-specific option or use a prepared file rather than trying to remove noise after the fact. Keep diagnostics on a separate stream when the source utility supports it.

Column-offset sorting is especially sensitive to whitespace. If one line has a shorter prefix than another, the same /+num can begin in different logical fields. If tabs appear, confirm whether SORT treats them as one byte or expanded display columns; do not assume screen position equals byte position. Prepare fixed-width input with a documented layout when position-based sorting is necessary. For variable-width records, use a parser that can extract and normalize the intended key first.

For reproducible outputs, store both the command and the environment assumptions beside the result: FreeDOS/kernel and SORT versions, COUNTRY/CODEPAGE configuration, input file checksum, and output checksum. A useful regression test includes duplicate keys and non-ASCII characters, then repeats after a cold boot. If the intended order changes, you can determine whether the data, collation tables, or utility changed.

Operational acceptance criteria

Before adopting SORT in a repeatable workflow, document the exact binary source/version, locale configuration, input encoding, comparison column, reverse policy, output target, maximum expected record size, and maximum expected records. Test a normal case, an empty file, a missing file, a nearly full memory case, and a line at the documented length boundary. Check what ERRORLEVEL means in the installed build instead of assuming all FreeDOS tools share an exit-code convention.

FreeDOS SORT is a focused utility for bounded line sorting. It is appropriate when the data is plain text, the comparison rule is character-based, and the dataset fits the available memory. It is the wrong tool for typed numeric fields, locale-neutral Unicode collation, stable ordering requirements not established by its documentation, arbitrarily large datasets, or structured records with quoting and delimiters. Selecting a tool that matches the data contract is more reliable than trying to infer database behavior from a small command-line sorter.

Related:

Sources:

Comments