I was thinking about how to best structure Host::RunShellCommand and ProcessLaunchInfo::ConvertArgumentsForLaunchingInShell based on previous discussions with greg.

One thing I don’t understand is why we need this use_default_shell argument. For starters, it seems like a better name for this argument would be requires_shell_expansion. As in, you should pass true if your command string might contain environment variables, commands stringed together with &&, etc. And pass false otherwise.

Is there any reason to not just always run it in a shell? just delete that argument to the function and let it always be true? It makes the code simpler and I don’t see what the advantage is to letting it be false. The end result is still the same.

Running in the shell is fragile, and for the most part (particularly when running GUI apps that don't really take command line arguments) an unnecessary complication. On a released OS with fully working shell & tools, this isn't so much of an issue. But the debugger is a tool that's got to survive on pretty bad OS versions to be useful. So the ability to get the shell out of the way for debugging is necessary from time to time.

I think the reason for using "run in shell" rather that "shell expansion" as the words for the setting is to emphasize that we aren't emulating shell expansion, but rather using your actual shell to prepare the command arguments.


Thanks for the explanation. I asked about the naming because it’s a little confusing to call a function named RunShellCommand and then pass it an argument that says “by the way, don’t run that in a shell”. It’s a real head-scratcher.