The calls of executables is done via this system call:
int execve(const char * path, char * const argv[], char * const envp[]);
How would you modify that system call signature to be able to carry that information? And what about how programs receive arguments?
int main(int argc, char * * argv)
How would you modify main()'s signature?
Take into account, the kernel has no notion that shells even exist. It has no need to know about features of particular programs in the upper layers, but now it's going to carry this information. All other programs, too. Right now, they're typically not aware that there is such a thing in the world as a shell, but now an integral part of what makes an executable an executable, its arguments, is going to come attached to this data structure that represents the use of a feature of some other program that has nothing to do with the executable itself.
What is a wildcard/glob/pattern? It's just some weird idea a program not different from any other program had. It's not particularly important. It's nothing all other executables ever needed to know about before.
Sorry I'm ranting. What I'm trying to convey is that typically software comes in layers, like an upside down pyramid, and the upper layers base themselves on the lower layers. The upper layers depend on the foundation that is the lower layer. This seems to go backwards, with the lower layer basing itself on a particular tiny insignificant piece of the upper layer. To the lower layer, that piece from the upper layer doesn't even need to exist. It can just disappear. The lower layer can run just fine without it. The kernel doesn't need the shell, and even shells don't need globbing. It's not a core feature even if it's common.
I'm fine with breaking rules and making a step towards a mess when the benefit is really worth it, but I'm not convinced this is worth it.
Listen, this article says `find -name * .jpg` is a common mistake (I put the space because of HN formatting). Yet, I don't think I've ever done that, and I don't believe I ever will. I trust the claim to an extent. When people are learning a new language (tongue), like English or Spanish, they'll make all sorts of silly grammatical mistakes, like saying "you was late" or similar. I'm sure they're very common, but as they gain experience or are a native speaker, they'll never commit those mistakes. Trust me that `find -name * .jpg` looks really wrong. It jumps out, and just like you'd never say "you was late", my fingers would never type that.
I wouldn't try to change English grammar so that "you was late" became acceptable. For whoever is making those types of mistakes, learning is a process, and that's fine.
Two arrays:
1. An array of all the Ys.
2. An array with one entry for each X. If X came from shell wildcard expansion, this entry is the index into the first array of the Y whose expansion resulted in X. If X did not come from wildcard expansion, this entry is some magic value that cannot be mistaken for an index into the first array.
Pass these arrays in the environment. No need for any kernel or standard library or language runtime modification to support it.
there are workarounds to that by adding eg. the target PID, but that probably comes with its own issues
I don't think my proposal would do that.
First, a clarification. When I said "For those from wildcard expansion, it would tell the program what the wildcard was" I meant the shell tells the program the full argument containing the wildcard, not just the wildcard part. E.g., if the argument was a?c which expanded to abc, the shell would tell the program it was a?c, not merely ?.
Let's say myprog takes one argument, which it expects to either be a file name or a wildcard in some pattern language that is not necessarily the same pattern language used by the shell.
Suppose myprog is invoked and it sees it has one argument, X. If the shell tells it that X did not come from shell wildcard expansion, myprog can safely use it.
If it does come from wildcard expansion and the source was Y, then there are a few cases.
1. Neither X nor Y contains any myprog wildcards. In this case, I'd have myprog go ahead and use X.
2. X does not contain any myprog wildcards, but Y does. Myprog can infer from this that it and the shell probably have overlapping wildcard languages. Report a "needs quote?" error.
3. X contains a myprog wildcard, but Y does not. Probably myprog and the shell use different wildcard languages. I'd guess its pretty unlikely that the user expects that a filename will contain a myprog wildcard, so I'd report an error in this case.
4. Both X and Y contain myprog wildcards. Go ahead an accept X, applying myprog wildcard expanstion to it. (Maybe first check that X and Y contain the same myprog wildcards, in the same order).
I'd probably add support in myprog for some optional flags to change the defaults in those cases so if you really want to do obscure things like have file names that contain myprog wildcards and use shell wildcards to provide those file names you can do it.