[2023-08-30T14:59:38Z] <ehawkvu> is anyone aware of an easier/more portable way to get a username from a uid?
[2023-08-30T14:59:55Z] <ehawkvu> I'm wanting to use uid's in my kiss fork, since they are easier to work w/
[2023-08-30T15:00:05Z] <ehawkvu> all I've come up with so far is this:
[2023-08-30T15:02:06Z] <ehawkvu> getent passwd | awk -F":" '$3 ~ /^<uid>$/ {print $1}'
[2023-08-30T15:05:19Z] <ehawkvu> I did see that it is possible to get the username using 'id'
[2023-08-30T15:05:45Z] <ehawkvu> but the command does not work on busybox, even though it works on ubase & gnucoreutils
[2023-08-30T15:45:49Z] <ehawkvu> also include toybox in that list
[2023-08-30T15:45:55Z] <ehawkvu> the command is "id -un 0"
[2023-08-30T15:55:58Z] <phoebos> does lisp not have a getpwnam(3) wrapper or equivalent?
[2023-08-30T15:56:12Z] <phoebos> both getent and that use of id aren't POSIX
[2023-08-30T15:58:20Z] <phoebos> if you can't do it in lisp, I would write a short (and portable) program in C
[2023-08-30T15:58:48Z] <phoebos> for example, https://github.com/aabacchus/kiss/blob/c-mix/bin/owner.c
[2023-08-30T16:00:44Z] <phoebos> if you want, you could just parse /etc/passwd, which will work 99% of the time
[2023-08-30T16:03:09Z] <ehawkvu> I'm using *emacs lisp*, which in hindsight was possibly a bad move? should be easy to port over though
[2023-08-30T16:04:30Z] <ehawkvu> I think I'm just going to parse /etc/passwd, since like you said it's
[2023-08-30T16:04:36Z] <ehawkvu> almost guaranteed to work
[2023-08-30T16:04:54Z] <midfavila`> it should be trivial to extract using extended regex in elisp
[2023-08-30T16:05:09Z] <midfavila`> i've only done a little bit of work with it though so i won't try and provide code
[2023-08-30T16:05:14Z] <midfavila`> just a suggestion for a jump-off
[2023-08-30T16:05:51Z] <phoebos> sounds good
[2023-08-30T16:06:12Z] <phoebos> that's all getpwnam does anyway
[2023-08-30T16:29:56Z] <ehawkvu> not the prettiest impl, but it works
[2023-08-30T16:29:57Z] <ehawkvu> https://github.com/ehawkvu/kiss.el/commit/894668edeaf74e081757469fb14050670108cbcf#diff-25f0eed012ed0b08c24eb27f87a3bfe69d67e67f1689b8a2b7ffb28638161adeR152
[2023-08-30T16:33:23Z] <ehawkvu> phoebos: how is bliss coming along?
[2023-08-30T19:02:02Z] <phoebos> ehawkvu: I've been preoccupied so haven't worked on it for a few weeks.
[2023-08-30T19:16:32Z] <illiliti> /etc/passwd is not portable either
[2023-08-30T19:26:23Z] <illiliti> see nss if you wonder why
[2023-08-30T19:26:34Z] <illiliti> strictly speaking there is no simple portable way
[2023-08-30T19:27:22Z] <illiliti> that's something posix need to fix actually
[2023-08-30T19:29:54Z] <ehawkvu> On the upside, the 3 systems that I care about (linux, freebsd, and openbsd) all have the same /etc/passwd format
[2023-08-30T19:30:02Z] <ehawkvu> I'm surprised that it isn't standard as of yet
[2023-08-30T19:30:17Z] <ehawkvu> (the way to retrieve the info, not /etc/passwd)
[2023-08-30T19:33:19Z] <illiliti> all these systems support nss in more-or-less way, so /etc/passwd won't work
[2023-08-30T19:40:25Z] <illiliti> ... no matter which format it has. I would rather use non-portable getent utility than deal with this tbh
[2023-08-30T19:40:52Z] <illiliti> because getent is guaranteed to work. parsing /etc/passwd by hand - never
[2023-08-30T19:41:26Z] <midfavila`> can also just target unix systems specifically instead of posix autism
[2023-08-30T19:42:18Z] <illiliti> unix systems support nss since ages
[2023-08-30T19:42:44Z] <illiliti> and/or nscd
[2023-08-30T19:56:01Z] <illiliti> i'm gonna investigate what options would be suitable for posix standardization
[2023-08-30T19:56:22Z] <illiliti> the first obvious option is id -un <id>, but I afraid we lost it since its behavior varies between implementations. some of them always expect username(as standard says), so mandating that id should be supported would be breaking change
[2023-08-30T20:14:05Z] <illiliti> i believe that simplest option would adding a new flag to id to treat username as uid.
[2023-08-30T20:16:49Z] <illiliti> that would allow implementations to implement new behavior while not breaking current
[2023-08-30T20:17:51Z] <illiliti> but another flag means another decade to actually become portable
[2023-08-30T20:35:35Z] <sad_plan> hi