By burying them in the framework....

Yes, exactly, just like database query processing in ORM systems and the like "buries" SQL injection countermeasures in a single place. It's a good thing.

There's abstraction confusion here, though. All SQL injection countermeasures and all it would take to protect the above CLI call is respecting the actual language you're using. That is, not gluing a query/command from strings.

Starting a subprocess via shell is could in particular be solved by a simple API of the form of:

  system('yourapp', ['option1', {'option2' : 'something'}]);

in your favourite language. Handling pipes and redirects gets more complex, but I see no prima facie reason why it couldn't look like this:

  pipe(system('yourapp', ['option1', {'option2' : 'something'}]),
       system('grep', ['n', 'i', 'foobar']),
       system('somethingelse', [], null, file("/dev/null")));

This assumes the --option=value syntax which while a de-facto standard on Unix-like systems is unfortunately not supported by all programs.

I agree that system() (in C and other langues that simply copied it) is a bad API. For shell escaping a command to start a process with a list of arguments would be enough, and even POSIX C has you covered there with vararg and array variants. [1]

[1] http://man7.org/linux/man-pages/man3/posix_spawn.3.html (or fork() + exec())