process info should not use String about sysinfo HOT 10 CLOSED

It's a good point. However, people generally require these pieces of information in a human readable format, so a String seems more accurate in here. However, I'm not against keeping Vecs instead, I just need to think what solution is the best.

from sysinfo.

I don't mean to be contrary, but the operating system itself really does not provide these data in a "human-readable" format. There's no guarantee that filesystem or environment entries are in any text encoding (much less UTF-8). It's convenient when the bytes in a process' name, executable name, or environment are ASCII or UTF-8, but since this library can't guarantee that condition, we should leave it up to consumers to convert to strings if they want. There are meaningful processing steps performed on paths and environments that rely on byte values (such as ASCII slashes, colons, and NULs), but these are really byte operations, not string operations.

Those of these values which are semantically paths would be reasonable to represent as PathBufs instead of Vec<u8>, but the environment is really just a binary blob.

The alternative would be to have two variants of accessor functions where one returns Option<String>, Result<String,Utf8DecodingError>, or String-but-maybe-panics and the other variant returns Vec<u8>/PathBuf, but I don't think it makes sense for every library returning binary data to also have variants of every function that attempt string conversion. It doesn't improve convenience significantly, and has the cost of roughly doubling API size and bloating the binary.

from sysinfo.

Program's name, environment variables, the program's path and the current working directory are human readable and meant to be. Based on that, which thing(s) do you think should remain a bytes array?

from sysinfo.

What text encoding can a human use to read them? Very often, UTF-8 happens to work, but the operating system does not guarantee that it will, and users of this library will run into cases where programs have non-UTF-8 filenames and environments. We can't just say "then don't do that", because non-UTF-8 filenames and environments are fully allowed by POSIX and the other relevant specifications, and used on occasion by existing programs.

Is there a reason we should not store paths as the Rust PathBuf type and environment variables as a type with the same semantics as char* (e.g. Vec<u8>, or OsString which is what libstd uses for environment vars)? Storing these as String means the library is unable to represent some of the filenames and environments it encounters; at the moment in panics in these cases. We can add UTF-8-checked String accessors for convenience, but will need to decide whether these should panic like the library does now or return Options.

from sysinfo.

Your arguments make sense. Well, then we should just provide some methods to have some conversions.

from sysinfo.

I'm currently stuck for lack of access to an OS X machine against which to develop that side of my suggested changes (I tried to get a VM working but haven't managed). I can upload a guess at working code to a fork, but I don't want to have to rely on a github-based CI service to see if my syntax in the OS X code is correct, much less my types and runtime behavior.

from sysinfo.

No problem, I can just update your code on OSX.

from sysinfo.

Sorry, really dropped the ball here, but I finally got around to this. I've made a PR which works well on Linux, but I expect type errors on the OS X side. Feel free to either accept the PR, work atop my commits first, fix the patch in review, or whatever's easiest.

from sysinfo.

I'll merge it on a temporary branch and then work on it.

from sysinfo.

Fixed by #83.

from sysinfo.