Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: «batch» mode to print values to stdout #42

Open
p4tpr0 opened this issue May 15, 2024 · 3 comments
Open

Feature: «batch» mode to print values to stdout #42

p4tpr0 opened this issue May 15, 2024 · 3 comments

Comments

@p4tpr0
Copy link

p4tpr0 commented May 15, 2024

Hello,

I would love having a «batch» mode to print output of ztop to stdout, in a machine-parsable way.
Unfortunately I can’t code…
Great tool anyway. It fills a gap between zpool iostat and top -m io.

@penryu
Copy link
Contributor

penryu commented Jan 13, 2025

Just another ztop fan here, but it's worth noting that all this information is already available in machine-parseable form via systctl kstat.zfs.*.dataset (FreeBSD) or /proc/spl/kstat/zfs/*/objset-*.

That said, it doesn't look like it would be too much trouble to just dump a single tick of tab-separated data to stdout if stdout isn't a tty. I'm tinkering with this in a branch now; nothing fancy, just emitting the pre-filtered, tab-separated values from app.elements() and exiting. This would have the advantage of being a cross-platform way to source the platform-specific information, while using the same filtering as the full ztop UI.

I can prepare an MR if @asomers thinks this sounds like a good idea.

@asomers
Copy link
Owner

asomers commented Jan 13, 2025

That would definitely have some uses. My only reservation is whether the UI would be general enough to satisfy most users. If not, would it be a better idea to split the app.rs file and its submodules into a separate crate?

@penryu
Copy link
Contributor

penryu commented Jan 13, 2025

There is some behavior in App that could be decoupled for this, namely things like data filtering/sorting (-c, -d, -f, -r, -s) from UI logic like -a / -t. (Some of those would be easier to decouple than others.)

I'm not sure if that's worth a whole new crate though... unless you're considering something like a dual lib/bin setup? Though even that could be done with just a [[bin]] section in the Cargo.toml. What are you thinking?

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

No branches or pull requests

3 participants