A lib crate for gathering system info such as cpu, distro, environment, kernel, etc in Rust.

This doesn't do much for now, but it paves the way towards avoiding a lot of the unwraps that are now present in the code.

And by the way, hello again!

I noticed that retrieving total package count was slowing down the output and was quite jarring. So I have proposed a new package retrieval method as well as new counting method that is quicker

| Method | Time to complete execution | |------------------------------ |-------------------------------------------------------- | | stock | real 0.38s user 0.32s sys 0.06s cpu 100% | | dpkg w/ stock count | real 0.36s user 0.31s sys 0.06s cpu 99% | | stock w/ new counting method | real 0.37s user 0.33s sys 0.04s cpu 99% | | dpkg w/ new counting method | real 0.08s user 0.04s sys 0.04s cpu 97% |

These are the numbers I got during my test, I have not tried this on other systems other than a laptop and a pc

This PR updates the info fields; cpu, device, distro, hostname, and user to be better supported on Android.

Example output from rsfetch on my Moto E4 phone:

$ ./target/debug/rsfetch -cDdhkmsuUC 0:

0─────────────────────────────────────────────────────0
│ CPU      │ ARMv7 Processor rev 4 (v7l)              │
│ Device   │ Moto E4 XT1765 (perry)                   │
│ Distro   │ Android 7.1.2 (aokp_perry-userdebug)     │
│ Hostname │ localhost                                │
│ Kernel   │ 3.18.63-NPL26.118-20-g9365253            │
│ Memory   │ 1868 MB                                  │
│ Shell    │ /data/data/com.termux/files/usr/bin/bash │
│ Uptime   │ 14h 50m                                  │
│ User     │ u0_a73                                   │
0─────────────────────────────────────────────────────0

Hi,

You assume in your implementation of memory() that "MemTotal" is always in the first line. If this is not the case, then a wrong value will be returned, which is however assumed as "correct" (here no error handling takes place, it is a "logical error"). I think the memory() function should be implemented in another way. I've written two example implementations, you can use one of them, if you want:

use std::io;
use std::fs;

/// Obtain total memory in a human readable size, outputs to a Result<String>
pub fn memory() -> io::Result<String> {
	let meminfo = fs::read_to_string(MEMINFO)?;
	for line in meminfo.lines() {
		if line.starts_with(MEMTOTAL) {
			let mut rsplit = line.rsplit(SEPARATOR_COLON);
			let size = match rsplit.next() {
				Some(x) => x.replace(UNIT[0], EMPTY_STRING).trim().parse::<u64>().to_io_result()?,
				None => return Err(io::Error::new(io::ErrorKind::Other, ERROR_02))
			};
			let mut current_multiplier = 1.0;
			while (size as f64) >= DIVISOR_F64.powf(current_multiplier) {
				current_multiplier += 1.0;
			}
			let mut memory = String::new();
			memory.push_str(&(format!("{:.2}", (size as f64) / 
				DIVISOR_F64.powf(current_multiplier - 1.0))).to_string());
			memory.push_str(&(UNIT[(current_multiplier - 1.0) as usize].to_string()));
			return Ok(memory)
		}
	}
	Err(io::Error::new(io::ErrorKind::Other, ERROR_01))
}

/// Obtain total memory in MB, outputs to a Result<String>
pub fn memory_mb() -> io::Result<String> {
	let meminfo = fs::read_to_string(MEMINFO)?;
	for line in meminfo.lines() {
		if line.starts_with(MEMTOTAL) {
			let mut rsplit = line.rsplit(SEPARATOR_COLON);
			let size = match rsplit.next() {
				Some(x) => x.replace(UNIT[0], EMPTY_STRING).trim().parse::<u64>().to_io_result()?,
				None => return Err(io::Error::new(io::ErrorKind::Other, ERROR_02))
			};
			return Ok(format!("{} {}", (size / DIVISOR_U64), UNIT_MB))
		}
	}
	Err(io::Error::new(io::ErrorKind::Other, ERROR_01))
}

pub trait ToIOResult<T> {
	fn to_io_result(self) -> io::Result<T>;
}

impl<T, E: ToString> ToIOResult<T> for Result<T, E> {
	fn to_io_result(self) -> io::Result<T> {
		match self {
			Ok(x) => Ok(x),
			Err(err) => Err(io::Error::new(io::ErrorKind::Other, err.to_string())),
		}
	}
}

const MEMTOTAL: &str = "MemTotal";
const MEMINFO: &str = "/proc/meminfo";
const ERROR_01: &str = "no MemTotal line found in /proc/meminfo!";
const ERROR_02: &str = "No memoryinfo in MemTotal line!";
const UNIT: [&str; 5] = ["kB", "MB", "GB", "TB", "PB"];
const DIVISOR_F64: f64 = 1024.0;
const SEPARATOR_COLON: &str = ":";
const EMPTY_STRING: &str = "";

const DIVISOR_U64: u64 = 1024;
const UNIT_MB: &str = "MB";

fn main() {
    println!("{:?}", memory());
    println!("{:?}", memory_mb());
}

Similar to MacOS Support #5, it would be nice if Windows was a supported target, It may be possible to reference winfetch for some inspiration.

This should probably include Win-Get and Chocolatey package counts.

this is the code:

use nixinfo;

fn main() {
    let cpu = nixinfo::hostname();
    println!("cpu: {:?}", cpu);
}

and this is the error. If I'm wrong somewhere let me know

cpu: Err(Os { code: 2, kind: NotFound, message: "No such file or directory" })

First of all, I love the initiative of the project. I started to learn Rust a few weeks ago and as my first project I set out to build a neofetch style tool, without realizing the existence of rsfetch, so I'd like to contribute here in what I can.

I saw that external commands are used to obtain information from the GPU, so I started to investigate how else could be done without depending on grep and lspci.

I found in the pciutils repository the following:

In runs on the following systems:

Linux (via /sys/bus/pci, /proc/bus/pci or i386 ports) FreeBSD (via /dev/pci) NetBSD (via libpci) OpenBSD (via /dev/pci) GNU/kFreeBSD (via /dev/pci) Solaris/i386 (direct port access) Aix (via /dev/pci and odmget) GNU Hurd (direct port access) Windows (direct port access, see README.Windows for caveats) CYGWIN (direct port access) BeOS (via syscalls) Haiku (via /dev/misc/poke) Darwin (via IOKit) DOS/DJGPP (via i386 ports) SylixOS (via /proc/pci)

There are many possible places to search, depending on the kernel (or operating system). But in some cases it's a matter of reading a plain text file. In order not to make the issue too long, I recommend the first part of this article. As you can see in the article, it is possible to read the vendor identifier, device identifier and class identifier.

I quote again the previous repository, the following:

The database of PCI IDs (the pci.ids file) gets out of date much faster than I release new versions of this package, so it is maintained separately.

It lives at https://pci-ids.ucw.cz/, where you can browse the database, download the most recent pci.ids file (e.g., by running the update-ids utility) and also submit new entries.

If we go through that website, we can corroborate that the GPU information (in addition to other devices that are not relevant) can be obtained from these ID's.

At first I thought that the pci.ids file should be downloaded regularly to keep it updated but, at least in Arch Linux, I found it in /usr/share/hwdata/pci.ids.

I'm not sure this is the best way to solve it, but I think it can work, without relying on system commands or external crates.