On Fri, 10 Nov 2023 at 12:09, Rob Landley <[email protected]> wrote: > > Which means that lib/portability.c hasn't got an implementation for BSD: > ... > Shouldn't be hard to add?
Yes, it should be quite straightforward. I'll find a few minutes to put a patch together. > > Similar issue, xattr_lget and xattr_get. And error: use of undeclared > > identifier 'ENODATA' > ... > if (errno==ENODATA || errno==ENOTSUP) len = 0; > > It's trying to gracefully fail if we fetched xattr info on a system that > hasn't > got xattr support. You can probably #define it to ENOTSUP. Linux uses it > quite a > bit: I think I've encountered a compiler error or warning from this sort of error, although that might have involved a switch statement (and duplicate cases from the #define). Can take a look after dealing with xattr. > The hard one is ps and friends. Last I checked there was a magic shared > library > to query proc info, and when I dug under the covers it was several different > syscall/fcntl/ioctl variants actually querying the data. Yes, top will also be in that group. These ones may be good candidates for GSoC or intern projects. > > Yes. In the fullness of time I expect we'll make the same (symlink) > > change in FreeBSD, but it still won't help here, because on FreeBSD > > bash is /usr/local/bin/bash. > > FreeBSD _ships_ local. As part of the distro, they deploy files into local. > > Define "local". Yes, I just mean that even if (when?) we turn /usr/bin and /usr/sbin into symlinks we'll still have the issue with /bin/bash. /usr/local is 3rd party software from the ports collection, not part of the FreeBSD base system. Every FreeBSD system will have /bin/sh. Bash may or may not be installed. _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
