On Mon, Jun 30, 2025, at 12:55 PM, Tim Murphy wrote: > How can make control what happens inside a shell command? How can > make wait until mkdir is executed by the shell and then expand $(file) > before the next shell command executes?
It doesn't have to control what happens inside a shell command. All it has to do is split the recipe into individual commands *before* expanding anything -- this is perfectly possible, since \n and ; *don't* separate commands when they come from expansion -- and then, for each command string, perform expansion, execute the result, wait for execution to complete. It's *already* waiting for execution of each command in a recipe before going on to the next one. > It's not $(file) that is causing this effect it's how all make > functions work of any kind. There is always expansion just before a > command is executed. When a command is sent to the shell make has no > further control of it. Again, just because that's how it works *now* doesn't mean it has to stay that way. As I said to Paul, there is plenty of precedent for macro languages having both expandable and non-expandable primitives that are introduced with the same notation. I'm not familiar with the guts of Make at all, but there is no fundamental reason why a $(file) within a command *could not* pass unchanged through function expansion and then be executed directly by the code that runs subprocesses (instead of actually invoking a subprocess).
