@whitequark Banning glob meta characters from files is how most platforms that followed this model worked. It’s probably a good idea, I’ve never created a file that contained one deliberately (I have created quite a few by accident).
Again, too late to put that particular genie back in the bottle for UNIX, but that doesn’t mean it was a good idea.
@david_chisnall OK, that does avoid the quoting issue and results in a consistent system, provided you can coordinate development between your shell and your filesystem interface.
I wonder though whether I'd prefer a system where a prefix (sigil character?) denotes the type of the token that follows. it's more verbose, but also unambiguous in a way that's compatible with existing systems and might be easier to read in a script as well
@whitequark The little language Jon Anderson built for the Fabrique build system had an explicit type for files, as distinct from strings. He did this so that you can add sandboxing things (the build system knows all of the files a tool should access and so can set policies around it) but I’ve found it something I miss in other environments.
I think there are two dimensions here:
What namespace are you talking about? UNIX defaults to the filesystem namespace because it was the only namespace originally (no network, no IPC except pipes) but these days you have different global (e.g. network) namespaces and different context-specific namespaces (e.g. the installed package namespace, or even the namespace of options this tool supports). Plan 9 addressed this by putting everything in the same namespace, but it often feels a bit shoehorned in.
What processing is done on this string to resolve it against things in that namespace.
Sigils feel like a good fit for the second because that should be a constrained set. Encouraging every application to do their own regex-like thing is probably bad, for example. The first set should be extensible, so sigils are maybe not the right thing here, but explicit namespaces that can be omitted when they are unambiguous might be nice.
@david_chisnall I agree! also, since namespaces are inherently system-wide, this structure enables a middle ground where each namespace comes its own little parser as a loadable shell component, but applications are purely declarative (but can depend on particular namespaces being available).
this parallels how the system operator would learn and think about commands: new namespaces come with higher cognitive effort than new commands, so the primitive is more heavyweight
