Re: Remaining things to remove mostly per the 80/20 rule Lassi Kortela 12 Aug 2019 12:39 UTC
>> Therefore I advocate we remove group-info:members from the >> group-info record, and make a note about user-supplementary-gids >> in the 3.6 section. >> > I perhaps jumped the gun and removed it. When I put on my implementor's > hat, it doesn't make the cut given that it's duplicates existing > behavior unless you're browsing, which is a use case we agreed we don't > care about supporting. I agree with this reasoning, though also don't see great harm in including it. We need to split it though, and decide whether to use a list or a vector. > Indeed, and I know about it only because I'm a historian and because of > my exposure to Original Formula Multics. But people still might > recognize "(pw_)gecos" even if they don't know the history behind it. > >> [ We keep pw_shell. ] I only now realized that Windows doesn't have an equivalent of pw_shell. (Well, it kind of does - in Windows parlance, the "shell" is the GUI window manager, and you can in principle replace the standard shell, or at least parts of it, through obscure partially documented means. I tried as a kid. It didn't work very well, which was the final impetus for me to install Unix where you can explore and customize everything. I think companies like Stardock have built a business on reverse-engineering that stuff and actually making it work.) I realize this is billed as a Posix SRFI, but I continue to advocate for cross-OS portability wherever possible. Otherwise we have to write separate Windows SRFIs at some point. But (user-info:login-shell) could just return #f on Windows. I don't see a problem with that. >> The trouble comes when TZ isn't set, in which case you have to look at >> /etc/timezone, the system default timezone. The trouble here is that >> it's sometimes a plain file containing the timezone name, and >> sometimes it's a symlink to a particular file in /usr/share/zoneinfo. > > You can't realize which is which by looking at the contents? I'd be > very leary of dispatching purely on whether it's a symlink or not. Hmm. Just looked at /etc on my Mac, and it's not clear how to portably parse the symlink path. Mine is "/var/db/timezone/zoneinfo/Europe/Helsinki" so you can get the desired "Europe/Helsinki" by taking the last two components. But there are many timezones that have only one component, and many that have three. >> Maybe it's better to bring back readlink after all. > > I'm personally less keen on it because for my backup use case you need > lseek to restore sparse files, and you have to know quite a bit more > about a Scheme's port implementation to correctly implement it vs. the > current procedures in the I/O section. I don't quite understand what you mean. Is readlink() harmful somehow, or you just don't see a useful application for it in a Scheme program?