Matthew S. Dippel The Official Blog*

submited by
Style Pass
2024-10-06 15:30:06

So, let's just be clear: this is insane and falls into the category of "just because you can doesn't mean you should." This is a "solved problem" that has many options which are easier to understand. This method offers exactly one benefit: the target platform I was working with for this project was mingw under Windows and, like WSL1, it had this very painful performance issue when a shell had to create a sub-shell -- basically, any time you $(run something) and that means "if your function returns anything except for an integer", it's going to have a serious cost to place that into a variable the convenient way. When diagnosing why a build script I wrote would ran almost instantly in a virtual Linux instance but took several seconds in mingw, I discovered the code that parsed the command-line took two seconds to complete. This version, combined with other hacks to eliminate sub-shelling everywhere else yielded a script that ran as fast on Windows as on Linux.

Of course, the reason it's a bad idea to use something like this is being that I wrote it a couple of years ago, I struggle to explain every part of it. The "dumbed down version" (read: mostly inaccurate) is that it first quotes the argument array, converts it to a string and does all of the "splitting of the short arguments" using "a string containing all of the arguments escaped in a manner compatible with later being converted to an array", and after a few replace operations it does just that, leaving you with an explicitly typed array and each Which, very poorly and probably slightly inaccurately summarized, merges the command line arguments into a properly escaped string, uses a few different matchers to rewrite that string (maintaining the proper escaping) and produces an array containing separated short flags and long flags with their parameter immediately after the correct flag (if a parameter is specified).

Leave a Comment
Related Posts