print_numeric: print mode in octal when the mode is too large

[Connor-GH]

No description provided.

[github-actions]

GNU testsuite comparison:

Skipping an intermittent issue tests/shuf/shuf-reservoir (passes in this run but fails in the 'main' branch)
Skipping an intermittent issue tests/sort/sort-stale-thread-mem (passes in this run but fails in the 'main' branch)

[sylvestre]

could you please add a test to make sure we don't regress in the future? thanks

[ChrisDryden]

Heres an example test for this scenario for chmod that you can use in test_chmod:

#[test]
fn test_chmod_mode_too_large_error_shows_octal() {
    let scene = TestScenario::new(util_name!());
    let at = &scene.fixtures;
    at.touch("file");

    scene
        .ucmd()
        .arg("10777")
        .arg("file")
        .fails()
        .stderr_contains("mode is too large (10777 > 7777)");

    scene
        .ucmd()
        .arg("77777")
        .arg("file")
        .fails()
        .stderr_contains("mode is too large (77777 > 7777)");
}

[Connor-GH]

Heres an example test for this scenario for chmod that you can use in test_chmod:

#[test]
fn test_chmod_mode_too_large_error_shows_octal() {
    let scene = TestScenario::new(util_name!());
    let at = &scene.fixtures;
    at.touch("file");

    scene
        .ucmd()
        .arg("10777")
        .arg("file")
        .fails()
        .stderr_contains("mode is too large (10777 > 7777)");

    scene
        .ucmd()
        .arg("77777")
        .arg("file")
        .fails()
        .stderr_contains("mode is too large (77777 > 7777)");
}

I had something similar, I have just been really busy. I am a university student.

[Connor-GH]

The test case results in this:

running 1 test
test test_chmod::test_chmod_permissions_too_large ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 4097 filtered out; finished in 0.01s

[codspeed-hq]

CodSpeed Performance Report

Merging this PR will not alter performance

_{Comparing Connor-GH:print_numeric-fix (7aad46d) with main (dbfbd0c)}

Summary

✅ 284 untouched benchmarks
⏩ 38 skipped benchmarks¹

Footnotes

1. 38 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[Connor-GH]

So the OpenBSD CI is failing because 7777 is considered to be in invalid value:

  thread 'test_chmod::test_chmod_permissions_too_large' panicked at tests/by-util/test_chmod.rs:310:45:
  Command was expected to succeed. code: 1
  stdout = 
   stderr = chmod: Inappropriate file type or format (os error 79)

Which is EFTYPE errno
This happens here in the OpenBSD code: https://github.com/openbsd/src/blob/8105fbd98be243a48cc198cd0c33d8bce8095608/sys/ufs/ufs/ufs_vnops.c#L465

// <snip>
if (cred->cr_uid && !vnoperm(vp)) {
		if (vp->v_type != VDIR && (mode & S_ISTXT)) // S_ISTXT == 0o1000
			return (EFTYPE);
// <snip>

This gets triggered because:

1. we are not uid 0
2. !vnoperm(vp) passes
3. we are not a directory
4. we have S_ISTXT set because (0o7777 & 0o1000) == 0o1000.

They are aware of this, see https://github.com/openbsd/src/blob/8105fbd98be243a48cc198cd0c33d8bce8095608/regress/lib/libc/sys/t_mkfifo.c#L225-L229

[ChrisDryden]

Are you still working on this? I think you just need to make that one line change in the test for BSD platforms and the PR is good to go.

[Connor-GH]

I am but I have been incredibly busy. I will try and make the change today.

…

On February 2, 2026 2:38:51 PM UTC, Chris Dryden ***@***.***> wrote: ChrisDryden left a comment (uutils/coreutils#10208) Are you still working on this? I think you just need to make that one line change in the test for BSD platforms and the PR is good to go. -- Reply to this email directly or view it on GitHub: #10208 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

[Connor-GH]

The change is ready. Please review when you have a chance.

[Connor-GH]

The OpenBSD test passes: https://github.com/uutils/coreutils/actions/runs/21632676699/job/62349346037#step:3:1366

[ChrisDryden]

Just waiting on the CI