same here… It is probably good warning the author that choosing a name starting with nix, while there is a NixOs distribution, and a Nix language, with tools like nix repl, nix-build, nix-shell, nix-store, nix-env, nix-doc… that such a name may create confusion.
Just my two cents.
On the other side, while the *nix acronym was already used in the 2000s, instead of Nix/NixOs, they could have chosen Nyx (the goddess of the Night).
Exactly! I came across this crate when I was looking for Nix store support functions, and sadly it was not it. Also, it didn’t support FreeBSD, if I recall correctly, so the crate might be misnamed.
This is my first lib crate in Rust. I feel like enough work has been put into it to warrant it’s own post.
Please let me know what you all think, I would really love to make this better!
It’s a crate which provides functions that output various system info in *nix such as cpu, distro, environment (de/wm), package counts, etc.
It was initially a part of my rsfetch (neofetch alternative in Rust) rewrite, but I felt like the info gathering functions would go great in a lib crate. And I’m quite happy with the results so far. I feel like this is going quite well for my first lib crate.
Might be worth noting that this won’t work at all on any non-Linux systems though (many don’t have /proc, and on some UNIX systems, files in /proc are not plaintext, many don’t have /sys). Would you be interested in advice on how to structure it to be more multi-platform friendly? Or do you want to keep it Linux-specific?
I plan on supporting BSDs as well for sure! Otherwise nix (as in *nix) would be a misleading title. I know mostly what I need to do to get them supported, I just haven’t gotten around to implementing it yet. I’m juggling around multiple projects right now, along with various in real life things.
If there are any other *nix operating systems that people use and would like support for, I’d be more than happy to add it.
Nice! I’ve had to write a lot of these functions for a project I’m working on so it’ll be convenient to use this in the future.
Just a note: I got a panic when I tried to get the window manager (I use sway on NixOS). Returning an io::Result for nixinfo::environment() and an Option for nixinfo::env() could work a lot better, especially for headless or strange systems.
I was a little sad that this had nothing to do with nix the distribution/package manager/language. :)
same here… It is probably good warning the author that choosing a name starting with nix, while there is a NixOs distribution, and a Nix language, with tools like
nix repl,nix-build,nix-shell,nix-store,nix-env,nix-doc… that such a name may create confusion.Just my two cents.
On the other side, while the *nix acronym was already used in the 2000s, instead of Nix/NixOs, they could have chosen Nyx (the goddess of the Night).
That makes three cents.
Better yet, there literally is a
nix-infocommand, generally used for people to include information alongside issue reports.Exactly! I came across this crate when I was looking for Nix store support functions, and sadly it was not it. Also, it didn’t support FreeBSD, if I recall correctly, so the crate might be misnamed.
Not misnamed, just not implemented yet. I feel like for the most part I have the Linux side covered, I still need to implement the BSD side of things.
I’ve been very busy lately juggling around multiple projects and in real life things, I just haven’t found the time to implement it yet.
This is my first lib crate in Rust. I feel like enough work has been put into it to warrant it’s own post. Please let me know what you all think, I would really love to make this better!
It’s a crate which provides functions that output various system info in *nix such as cpu, distro, environment (de/wm), package counts, etc.
It was initially a part of my rsfetch (neofetch alternative in Rust) rewrite, but I felt like the info gathering functions would go great in a lib crate. And I’m quite happy with the results so far. I feel like this is going quite well for my first lib crate.
Very cool!
Might be worth noting that this won’t work at all on any non-Linux systems though (many don’t have
/proc, and on some UNIX systems, files in/procare not plaintext, many don’t have/sys). Would you be interested in advice on how to structure it to be more multi-platform friendly? Or do you want to keep it Linux-specific?Thank you.
I plan on supporting BSDs as well for sure! Otherwise nix (as in *nix) would be a misleading title. I know mostly what I need to do to get them supported, I just haven’t gotten around to implementing it yet. I’m juggling around multiple projects right now, along with various in real life things.
If there are any other *nix operating systems that people use and would like support for, I’d be more than happy to add it.
And yeah, advice would be great! :)
Nice! I’ve had to write a lot of these functions for a project I’m working on so it’ll be convenient to use this in the future.
Just a note: I got a panic when I tried to get the window manager (I use sway on NixOS). Returning an
io::Resultfornixinfo::environment()and anOptionfornixinfo::env()could work a lot better, especially for headless or strange systems.Thanks!
Returning a
Result<String>was actually the next thing I had listed fornixinfo. :)And I’ll look into
Option. I’ve never worked withOptions before and this crate was the first time I really started working withResult.Thanks for the note.
Edit:
Result<String>andOption<String>have been implemented forenvironment()andenv()respectively.