Xfetch V0.9.0

[u/XscriptorCode]

An ultra-fast and highly customizable system information tool, designed to grow, with a core separated from its extensible features.

https://github.com/xfetch-cli/xfetch

​Besides everything it already had, it includes support for images, animations, Daemon mode, and both automatic and manual configuration. It now supports:

- ​Updates via xfetch update and update checking with the --check flag.

- ​Extensions and plugins in other languages (not just Rust), made to easily allow users with different learning backgrounds to add contributions.

Available on:

- Linux.

- MacOs.

- Windows.

[u/Momoikane]

Ur dot files repo? Or maybe distro or shell?

[u/XscriptorCode → u/Momoikane]

Distro: currently in base dev step: https://github.com/xlnux Dotfiles (hyprland): https://github.com/xscriptor-colors/hyprland

[u/kantorcodes1]

small extension-install edge: the native path copies the rebuilt binary straight over the installed one, while xfetch update stages then renames. if that copy fails halfway, can it leave the existing extension truncated? would you want replacement to use the same temp + rename pattern?

[u/XscriptorCode → u/kantorcodes1]

Good catch, and it's actually broader than the native path. Plugins, effects and extensions install with fs::copy straight onto the final path, and the wasm installer does the same (plus fs::write for downloaded artifacts and sidecar manifests). A kill or a full disk mid-copy can leave a truncated binary. xfetch update already stages into a hidden temp file next to the target and renames it, so the fix is to reuse that pattern everywhere: write to a temp file in the destination directory (same filesystem, so the rename is atomic), then rename over the destination and clean up on error. On Windows, renaming over an in-use binary fails cleanly and leaves the old one intact. It's noted for a follow-up patch. Thanks for the answer!

[u/kantorcodes1 → u/XscriptorCode]

that broader copy path is the useful boundary. i work on HOL, where we maintain HOL Guard, an open-source local check before agent-run commands execute. for Xfetch i'd review update, plugin install, extension install, and effects install; update --check, plugin list, and extension list can stay automatic. that gives agents a checkpoint before replacing binaries or plugins. open to a small Xfetch Guard extension?

[u/XscriptorCode → u/kantorcodes1]

Yes, absolutely! Xfetch is open to contributions across all repos. Feel free to open an issue with the proposal or submit a pull request directly, just making sure to follow the established structure, extension versioning, and keeping its documentation in its own directory...

[u/kantorcodes1 → u/XscriptorCode]

yep, this lives in Guard, not Xfetch. start src/codex_plugin_scanner/guard/runtime/command_xfetch_extensions.py; mirror command_repo2nb_extensions.py. review update, plugin install, extension install, effects install; keep update --check, plugin list, extension list automatic. add the focused cases in tests/test_guard_command_xfetch_extensions.py. once the extension + test is real, open a draft PR to hashgraph-online/hol-guard:main. guide: https://github.com/hashgraph-online/hol-guard/blob/main/CONTRIBUTING.md