@whitequark

I don’t think I understand this. The escaping problems happen as a result of expanding globs early. If you pass *.txt as an entry in argv, you don’t need to escape it. The receiving tool then passes it to glob, which returns an array of paths. If you’re matching something that isn’t a file path, you can use `fnmatch‘ and get the same behaviour, but again you’re dealing with structured data.

Quoting is a requirement when you are serialising structured data. If you expand globs and pass them as a string, you have introduced a requirement for quoting. If you pass all of the arguments to a program as a single string, you have similarly introduced a requirement for quoting. The shell performing early expansion adds a bunch of quoting requirements (POSIX shells not having array types and writing arguments as a string, even though they are passed as a vector of strings, also introduces quoting requirements). These are not intrinsic to the problem.

Windows requires a load of quoting because you flatten a structured vector of arguments to a single string.

UNIX requires quoting in the shell because the shell expands globs to a single string.

VMS, as I recall, had neither of these problems because it passed arguments as a vector and provided a shared library routine for expanding file patterns.

@david_chisnall in this system, how do you move a file called literally `*.txt`? or do you propose to ban glob metacharacters from filenames?

@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