I have a "file attributes fixer" program for Windows, written in Powershell. I am hoping to learn Nim by porting/re-implementing a Linux version of the same tool in Nim.
I was surprised to run into what seem, to me, to be basic gaps in the Nim standard libraries. What I was looking for, but not finding, are native high-level Nim interfaces for-
I know the std/posix module exists, but these are raw interfaces using cstrings etc., and writing native wrappers for these is beyond my newbie skill level.
Firstly, am I correct about these being gaps in the std library?, and then- is there a 3rd party contributed library out there that provides these as native Nim interfaces, or are even new users of Nim writing their own wrappers for this stuff?
As for your "basic" needs I'm happy to tell you you're very special and they are not "basic" for I and many others have never needed these features. Without its corresponding command line a process-ID is rather useless so you need a wrapper for /proc/<pid>/cmdline too and every such feature needs its Windows implementation...
Per treeform's point, pure/os.nim:proc CreationTime uses st_ctim which is the Unix c-time which is more of a "modification time of the metadata" timestamp than the file creation time. E.g., if you change file permissions it gets updated. Historically, many teachings expanded the 'c' as "creation", but at some point "change status" became popular, too. Anyway, it's a complex timestamp as only some metadata changes bump it. E.g., file writes to increase size which is also metadata do not change it.
There is a cligen/statx that wraps the system APIs to get what has become known in Unix realms as "b-time" (for "birth time"). That cligen/statx module is used a lot in the already Araq-mentioned bu and would be found quickly on a transitive dependency search. I tried to make it so that it could fallback to only-stat supported. Example usage might best be seen in lc which is a file listing utility. Anyway, if you are doing CL utilities on Linux which it sounds like @incans is doing, there is much you might find useful in cligen/.
I believe the naming "birth time" was actually copied from FreeBSD 5.0 (not sure about the version), but I don't really use BSDs anymore so that cligen/statx module is a bit limited. I also think OSX supports it recently as well, at least on some filesystems. I'm happy to add in some when BSDs, though. PRs are welcome.
As to "basic", yeah, that's a "loaded term" (an English expression long before overloading in PLang's!). It means different things to different people or the same person in different contexts. Much human communication is burdened with many unspecified assumptions. I put that module in cligen/ because it is a CLI framework and CLI utilities often manipulate files and file metadata is just a common-need for such and my initial users of lc and procs were 3 or 4 Nim outsiders where a "2-clone+build copy-paste" seemed friendlier to them than "learn what Nimble does" or a 5 or 10 clone variant. Quite a few things are in cligen/ that might "logically" be separate, more a la carte packages for this same reason. { Admittedly, if they are copy-pasting, the granularity hit might not be much, but many people copy paste line-by-line for whatever reasons and package granularity purity seemed not worth it. }
I do acknowledge the posix module is there, but as noted in the documentation for that module these are low level C-style interfaces. As someone new to the language, needing to learn the conventions around wrapping native interfaces adds a significant extra hurdle to the learning curve.
If there is a a "wrapper style guide", at least for basic stuff like adapting variable types that would help. However its clear I think that in some cases (i'm thinking of user account information in particular) it's not just a case of variable wrangling. A native Nim API for user account info would I think be very unlike getpwent(), and i'm not confident my rudimentary skills are up to defining one from scratch.
In this case the need for the parent process ID was to be able to work out whether the process was being run in the background as a timer job, when (I believe) the ppid will be 1 for processes started by systemd. I don't need the full command line, the parent ID should be enough.
I believe it is also possible to get background/foreground status in linux by looking at the assigned tty, but that's arguably even more specific to the working of a specific OS than looking at process IDs.
For once the concept is quite similar in Windows where the "session ID" is 0 for jobs running as background tasks.