refactor uu_df so crate users can call df without printing to stdout.

[philocalyst]

refactor uu_df so crate users can call df without printing to stdout. This is for tackling this nushell issue.

It opens uu_df for crate users that want structured filesystem data instead of parsing the text table printed to stdout. This allows the people over at nushell (probably me, who will write the PR), to incorporate it cleanly. Other people too, I'm sure!

The new API follows the same pattern as the recent uu_ls work (thanks @fdncred !):

• df_with_output gathers filesystem data and sends it to a caller-provided output sink.
• DfOutput supports both batch and streaming consumers.
• StreamingOutput collects Filesystem values for awesome programmatic use.
• TextOutput preserves the existing command-line table behavior.
• df remains the normal text-output entry point and delegates through the (new!) shared path.

Filesystem is now public because it is the structured data crate users need. I kept the existing fields as the public API surface, since they already expose the mount information and usage data without requiring an additional wrapper type. Also plenty of nice documentation is around!

Some notes:

• CLI output behavior unchanged
• StreamingOutput is meant as the easiest starting point for nushell or other crate users.
• If downstream projects start depending on this, we should treat these public types and functions as a real API and avoid changing them casually.

Would love feedback!

[github-actions]

GNU testsuite comparison:

Skip an intermittent issue tests/cut/bounded-memory (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)
Congrats! The gnu test tests/expand/bounded-memory is now passing!
Congrats! The gnu test tests/printf/printf-surprise is now passing!

[codspeed-hq]

Merging this PR will degrade performance by 19.55%

⚠️ 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 regressed benchmark
✅ 316 untouched benchmarks
⏩ 46 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Memory	cp_recursive_deep_tree[(120, 4)]	562.5 KB	699.2 KB	-19.55%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing philocalyst:open-df (fcc342c) with main (6a942ba)}

Footnotes

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

[philocalyst]

Believe the tr failure isn't my own.

Have an idea for a commit that should fix the perf issues! Awesome tooling y'all have.

[philocalyst]

I've only added code in df/ so I don't believe the cp issue is mine, either.

[oech3]

It is very hard to distinguish pub fn just for our project and pub fn which can be used externally and I don't want to extremely care about removing pub fns when we stoped using it.

[philocalyst]

@oech3 You're encouraging me to move to a wrapper type?

[oech3]

Sorry. I don't understand what you are asking.

But... why does nushell need to use internal functions instead of just calling uu_app? It is much easier than changing many part of uutils itself.

[fdncred]

@oech3 because nushell outputs structured data and not just strings that println!() or eprintln!() outputs. Nushell also needs to be able to pass parameters into the crate with nushell parsing the parameters and the passing those values into the crate. Nushell also creates "nice" error messages from this data if necessary with spans. Calling uu_app wouldn't help with any of this.

[oech3]

I think it is impossible to guarantee stable API at here.

[oech3]

Parsing stdout would be nightmare, but it is the most stable API.