Skip to content

vms-e76: SORT honors /KEY=(POSITION:n,SIZE:m) field-based sort (facade-risk -> real) - #1050

Merged
baron-3dl merged 1 commit into
mainfrom
work/sort-key
Sep 2, 2026
Merged

vms-e76: SORT honors /KEY=(POSITION:n,SIZE:m) field-based sort (facade-risk -> real)#1050
baron-3dl merged 1 commit into
mainfrom
work/sort-key

Conversation

@baron-3dl

Copy link
Copy Markdown
Contributor

What

Compat register facade-risk → real for utilities$sort. cmd_sort did a whole-line case-insensitive qsort and ignored /KEY entirelySORT/KEY of a keyed file silently produced whole-line order while reporting success. The SORT verb did not even declare a KEY qualifier.

Fix

  • Declare KEY on the SORT verb as CDU_VT_LIST (q_sort, dcl_builtin.c), so /KEY=(POSITION:n,SIZE:m) parses and validates.
  • cmd_sort honors /KEY: parses the value (POSITION/SIZE, optional DESCENDING; parens and :/= tolerated) and sorts on the [pos,size] field via a key comparator (1-based VMS column, case-insensitive, /REVERSE XOR DESCENDING). No /KEY keeps the whole-line path unchanged.

Ground-source

tests/dcl/test_sort_key.sh (DCL conformance harness) sorts an input whose whole-line order (by column 1) differs from its keyed order (by the digit at column 5) and asserts the keyed sort yields zzz,mmm,aaa while the whole-line sort yields aaa,mmm,zzz — so the old ignore-/KEY behaviour reddens the keyed assertion. The parse + field-extraction + comparator were additionally verified with a standalone harness (single key, descending, alternate POS=/SIZE= spellings, non-key reject).

Register

utilities$sort: partial/facade-risk → implemented/real. Documented follow-ups (not facades): secondary keys / multiple /KEY tie-breaking use the first key only, and MERGE is a separate absent utility (vms-a85a). Surface regenerated. Off-cluster, self-contained.

🤖 Generated with Claude Code

…e-risk -> real)

Compat register facade-risk row utilities$sort: cmd_sort (src/vmsdcl/dcl_cmd_misc.c)
did a whole-line case-insensitive qsort and IGNORED /KEY entirely -- SORT/KEY of
a keyed file silently produced whole-line order while reporting success. The SORT
verb did not even declare a KEY qualifier.

Fix:
- Declare KEY on the SORT verb as CDU_VT_LIST (q_sort, dcl_builtin.c), so
  /KEY=(POSITION:n,SIZE:m) parses and validates.
- cmd_sort parses the /KEY value (POSITION/SIZE, optional DESCENDING; parens and
  ':' vs '=' tolerated) and, when present, sorts on the [pos,size] field via a
  key comparator (1-based VMS column, case-insensitive, /REVERSE XOR DESCENDING).
  No /KEY keeps the whole-line path unchanged.

Ground-source: tests/dcl/test_sort_key.sh (run by the DCL conformance harness)
sorts an input whose whole-line order (by column 1) DIFFERS from its keyed order
(by the digit at column 5), and asserts the keyed sort yields zzz,mmm,aaa while
the whole-line sort yields aaa,mmm,zzz -- so the old ignore-/KEY behaviour
reddens the keyed assertion. The parse + field-extraction + comparator were also
verified with a standalone harness (single key, descending, alt POS=/SIZE=
spellings, non-key reject).

Register: utilities$sort partial/facade-risk -> implemented/real. Documented
follow-ups (not facades): secondary keys / multiple /KEY tie-breaking use the
first key only, and MERGE is a separate absent utility (vms-a85a). Surface
regenerated.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@baron-3dl
baron-3dl merged commit 1812b76 into main Sep 2, 2026
122 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant