>     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.