introduce IS_POSIXLY_CORRECT static

[xtqqczze]

Follow-up #11853

[xtqqczze]

Since we control the entrypoint, we could use unsafe mutable static instead:

static mut IS_POSIXLY_CORRECT: bool = false;

pub fn uu_main() {
    unsafe {
        IS_POSIXLY_CORRECT = env::var_os("POSIXLY_CORRECT").is_some();
    }
}

fn is_posixly_correct() -> bool {
    unsafe { IS_POSIXLY_CORRECT }
}

[github-actions]

GNU testsuite comparison:

Skip an intermittent issue tests/pr/bounded-memory (fails in this run but passes in the 'main' branch)
Skip an intermittent issue tests/tail/inotify-dir-recreate (fails in this run but passes in the 'main' branch)
Skip an intermittent issue tests/tail/symlink (fails in this run but passes in the 'main' branch)
Skip an intermittent issue tests/tail/tail-n0f (fails in this run but passes in the 'main' branch)
Skipping an intermittent issue tests/misc/io-errors (passes in this run but fails in the 'main' branch)
Congrats! The gnu test tests/seq/seq-epipe is now passing!
Congrats! The gnu test tests/tail/pipe-f is now passing!
Note: The gnu test tests/env/env-signal-handler was skipped on 'main' but is now failing.

[codspeed-hq]

Merging this PR will improve performance by 51.74%

⚠️ Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.

Open the report in CodSpeed to investigate

⚡ 1 improved benchmark
✅ 366 untouched benchmarks
⏩ 50 skipped benchmarks¹

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
⚡	Simulation	echo_consecutive_calls	257.6 µs	169.7 µs	+51.74%

Tip

Curious why performance improved? Comment @codspeedbot explain why performance improved on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing xtqqczze:static-posixly-correct2 (576bcc7) with main (4bae306)²}

Footnotes

1. 50 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. ↩

2. No successful run was found on main (a5d6966) during the generation of this report, so 4bae306 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[cakebaker]

Hm, what's the benefit of these changes? For example, in mktemp.rs there is a single check for the POSIXLY_CORRECT env variable in uumain, and using a global LazyLock seems overkill. But maybe I'm missing something...