comm, checksums, file, enhanced grep and jq

[cramforce]

Command	Description	Tests
comm	Compare sorted files line by line	15 tests
md5sum	MD5 hash calculation (using Node crypto)	7 tests
sha1sum	SHA1 hash calculation	2 tests
sha256sum	SHA256 hash calculation	3 tests
file	File type detection (using file-type npm package)	17 tests

Enhanced Commands

Command	Enhancement
grep	Added -P / --perl-regexp flag (uses JS regex which is PCRE-compatible)
jq	Added to_entries, from_entries, with_entries, recursive descent .., plus many more functions

jq New Functions

• to_entries, from_entries, with_entries
• .. (recursive descent)
• paths, leaf_paths
• any, all
• ascii_downcase, ascii_upcase
• floor, ceil, round, sqrt, abs
• tostring, tonumber
• now (current timestamp)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Review	Updated (UTC)
just-bash	Ignored		Dec 31, 2025 4:15pm

[vercel]

Additional Suggestion:

The option parsing for combined short flags incorrectly includes 'P' as a valid flag without handling its required numeric argument.

View Details

📝 Patch Details

diff --git a/src/commands/xargs/xargs.ts b/src/commands/xargs/xargs.ts
index 3897277..ffede6a 100644
--- a/src/commands/xargs/xargs.ts
+++ b/src/commands/xargs/xargs.ts
@@ -59,7 +59,7 @@ export const xargsCommand: Command = {
         // Check for unknown short options
         const _valid = true;
         for (const c of arg.slice(1)) {
-          if (!"0trnIP".includes(c)) {
+          if (!"0tr".includes(c)) {
             return unknownOption("xargs", `-${c}`);
           }
         }

Analysis

Combined short options validation incorrectly includes options that require arguments

What fails: xargsCommand option parsing at line 62 validates "0trnIP" as valid characters for combined short options, but the combined option handler (lines 67-69) only processes options that don't require arguments. This allows invalid usage like xargs -Pt 2 or xargs -tn 2 to pass validation when they should be rejected.

How to reproduce:

# Test case 1: Combining -P with other flags
echo "a b c" | xargs -Pt 2 -n 1 echo

# Test case 2: Combining -n with other flags  
echo "a b c d" | xargs -tn 2 echo

With real GNU xargs, -Pt 2 fails immediately: xargs: invalid number "t" for -P option

With the buggy code, it incorrectly accepts the combined form because 'P', 't', 'n', 'I' are all in the validation string, but then fails to parse the argument to 'P' or 'n', causing the argument to be treated as a command argument instead.

Result: For -Pt 2 -n 1 echo, stderr shows bash: 2: command not found (the '2' was incorrectly treated as a command instead of an argument to -P)

Expected: Should return exit code 1 with stderr xargs: invalid option -- 'P' (since -P cannot be combined with other options as it requires an argument)

Root cause: In Unix option parsing conventions, options that require arguments cannot be safely combined with other short options in a single argument cluster. Options requiring arguments:

• -I REPLACE - requires argument
• -n NUM - requires argument
• -P NUM - requires argument

Options that don't require arguments (safe to combine):

• -0 / --null - flag
• -t / --verbose - flag
• -r / --no-run-if-empty - flag

The validation string was changed from "0trnIP" to "0tr" to only allow the options that safely work in combined form.

Reference: GNU xargs manual lists -n max-args, -I replace-str, and -P max-procs as all requiring arguments.