A programming language should not be parsed and neither lexed on the filesystem layer. This is what REPL or interpreters are for.
Counter question: would you have all C++ macros from libboost as symlinks on the filesystem, too? How would that work? /usr/bin/C++/[ and /usr/bin/bash/[ maybe? What's the difference of the operator behaviors, given that macros exist?
If you're not understanding where I am getting at: these types of hacks were the reason for a lot of fuckups and a lot of CVEs in the past. Directly or indirectly. I'd even encourage every distro to use busybox at this point, just for having a centralized entrypoint for your shell scripts.
I have come to love shells with little special syntax, namely fish, so generally write
if test
rather than
if [
in any shell. I'm not particularly a fan of special syntax, let alone external commands pretending to be special syntax.
But restricting commands to specific character sets also seems a bit cheesy to me. It seems more natural that a character is a character. I can see the other side here, though.
I'm curious about those CVEs. Surely any script involving the hijacking of `[` to obfuscate malicious code could also just as well have hijacked `test` (wherever `test` is not a shell built-in), right?
> I'd even encourage every distro to use busybox at this point, just for having a centralized entrypoint for your shell scripts.
For operating system scripts, I guess that's fine. But administrators who are writing their own scripts should choose a shell that's actually pleasant to read and write, and ship an appropriate runtime, including external commands. You can do this today in a portable way with Nix or Guix and a bit of footwork, just as well with bash as with Python.
If you're writing scripts in something other than your daily login shell, you might as well use a non-shell programming language, because you're now losing the advantage of writing in a language that you practice constantly. And BusyBox is not a pleasant daily login shell, so you shouldn't use it for that, either.
> Surely any script involving the hijacking of `[`
It's not about hijacking of any binary, it's about mutation of state, and having to keep the same parsing state across multiple binaries, which is very bad practice (apart from USR1/2 and stdout/stdin not even remotely being made for that).
Keep in mind that the architecture we are speaking about was implemented when an OS had less than 20 binaries overall.
Now we have thousands of binaries with absurd levels of complexity, and nobody really knows what's going on anymore.
This still seems very handwavey to me with respect to the actual vulnerabilities. And the only 'split parsing' going on is external commands parsing arguments passed to them. `test` doesn't parse bash or any other shell. `[` is not special, either; it doesn't have to communicate anything back to the shell invoking it about how to parse the rest of the program, either!
Are you categorically against shell scripting (the invocation of external binaries as commands), then?
Counter question: would you have all C++ macros from libboost as symlinks on the filesystem, too? How would that work? /usr/bin/C++/[ and /usr/bin/bash/[ maybe? What's the difference of the operator behaviors, given that macros exist?
If you're not understanding where I am getting at: these types of hacks were the reason for a lot of fuckups and a lot of CVEs in the past. Directly or indirectly. I'd even encourage every distro to use busybox at this point, just for having a centralized entrypoint for your shell scripts.