Come on. The problems you list (in the introduction) are: - control characters in filenames: irrelevant to non-shell languages - leading dashes in filenames:

Come on. The problems you list (in the introduction) are: - control characters in filenames: irrelevant to non-shell languages - leading dashes in filenames: doesn't affect normal Python/non-shell languages; for example, unlike in shell, directory walking in Python is implemented by calling os.walk, not execing a separate process "find" and parsing its output - the lack of a standard character encoding scheme: doesn't affect Python 3, now that the filesystem encoding system is complete and cleanly handles encoding errors - spaces in filenames can cause problems: irrelevant to non-shell languages - special metacharacters in filenames cause some problems: irrelevant to non-shell languages As you admit, these problems are worse in shell (I contend, only meaningfully exist in shell). So why is your article written using shell scripting for its examples? - If you really believe that shell is worse for this, then you should be warding people away from shell - If you really believe these problems are pervasive, take on the hard target, instead of going for the easy target of shell - If these problems really still affect Python programmers who believe they are safe from these footguns that are so prevalent in shell, then you should be warning them, not the shell programmers who already know that shell is an incredibly hard language to write robust programs in But as your article is using shell for its examples, I can't help but conclude that this is just another piece of shell-zealotry. If you seriously want to fix this problem for people, you should be advising them to stop writing programs in shell. That is undeniably the fastest and easiest mitigation to the majority of these problems. On that, surely you must agree. ----------------------------------------------------------------- An aside on the topic of leading dashes in filenames: it's true that any program parsing filenames from the command line will run into this issue where data and options can be confused. You diagnose this as an issue with filenames, but I disagree: This is an issue with traditional argument parsing, which is a very poor serialization format. Any number of alternative serialization formats would avoid this issue; for example, https://github.com/NuxiNL/argdata https://github.com/NuxiNL/argdata does not have this problem.