Re: The case for glob in SRFI 170 Lassi Kortela 11 Dec 2019 20:45 UTC
> In the sense that it adds a lot of semantics on top of syscalls. > > GIven the presence of tempfiles, groups, and users (all completelyl > justified IMO), that ship has sailed in SRFI 170. That's true, but there is nothing in the kernel about those types of objects. Their basic infrastructure comes from userland libraries whereas glob is just convenience over directory listings that come from the kernel. The kernel doesn't have procedures to list users or groups or generate tempfile names. There is also one obvious way to get user and group info (use libc which uses /etc/passwd, NIS, etc.) but many ways to glob. I mean that the glob syntax is arbitrarily chosen, not system-dependent. The user and group stuff is not orthogonal to the system in the same way; we have to follow the system's rules. A username glob would be an example of a similar orthogonal facility for users: the glob syntax would be up for debate and could be implemented on top of a system-dependent user-fold procedure. > In any case, Posix > makes no distinctions (nor should it) between syscalls and library > operations. I didn't mean it that literally; I meant plotting a course that stays close to the syscall surface unless there is a clear reason to diverge. By all means most implementations should use the libc wrappers for years to come. > That's why I think the syscall API is a better target to aim for. > > Except that it is completely non-portable. I tried intersecting Posix, > Linux, and FreeBSD in a very early concept of this SRFI, and it was a mess. The machine-level calling conventions are not portable but the C-source-level endpoints are about the same (with many extra syscalls and flags per each system). > I agree that a complex globber doesn't belong in SRFI 170. But a simple > globber (and I'm fine with calling it simple-glob) still handles a bunch > of use cases. In the shell I almost never use anything but *, ?, [...], > and braces, and braces don't care about the state of the filesystem: you > can just expand them before globbing. All this except the braces has > been around since the 7th Edition, although the glob library used to be > part of the shell source. If you want to use a Scheme REPL as a shell, lots of things would be handy there that IMHO would better go in their own SRFI. The first thing you'd want is something like (cd) and (ls) procedures, etc. It becomes a user interface concern, which yields quite different design priorities from a lower-level interface that's meant to abstract the parts that differ between systems. > The best (especially when we don't have it yet) is the enemy of the > good. In the meantime, simple-glob will be easy to specify and easy to add. I worry about the total complexity. complex-glob will be a superset of simple-glob. If we put simple-glob in SRFI 170, users will soon have both. It's like regexp engines, people now have classic Unix AND posix AND perl-compatible variants. The old ones can never be deprecated.