I have a custom platform.txt for some hardware I have developed. One of the post build steps requires passing the program size as a variable on the command line to a program that patches the output file.
I can call the patcher using recipe.hooks.objcopy.postobjcopy.#.pattern and I can call the program that will give me the program size, but I can't figure out a way to capture the output of that as a variable.
It looks like Arduino has some regular expressions for parsing and outputting the size when using the recipe.size.pattern but I can't figure out a way to capture that result and send it to the next pattern.
Yea I was just hoping if there was a way to incorporate that into the existing Arduino script it would eliminate yet another thing to be maintained but if it's not achievable then that's the way I'll go.
Ouch, that is annoying, and it's an upstream bug in Go, so I guess it's not something Arduino can fix.
I notice this:
Go encodes child process parameters in a way that is understood by most programs. Go uses rules similar to what CommandLineToArgvW implements.
Unfortunately, your child process is cmd.exe (cmd.exe is called to execute the batch file you've requested). And cmd.exe parses its input parameters differently.
So I think if you were able to create an executable as a replacement for the batch file, you wouldn't have this problem. I don't have any experience with it, but I know there are tools to make a .exe from a Python script, so maybe that would provide a relatively simple alternative to a batch file.
Technically I guess I could incorporate it into the output file patcher (since I'm actually writing that executable) but it's also used in non-Arduino situations so that might get messy.
I was able to get around it in the batch file for now by using cd %~dp0 to move to the batch file's home directory, that's being run from the Arduino Tools directory where all of my file processing applications are stored which means I don't need to pass an actual path for those applications to the batch file.
So far so good but we'll see how portable it is once I try to deploy it...
Nice! Thanks for taking the time to share your solution. I'll try to remember that workaround. I actually am the one who set up those scripts in ATTinyCore and I've done the same sort of "wrapper script" thing in a couple other boards platforms as well, so there's a good chance I've introduced incompatibility with paths containing spaces. I tend to instictively avoid creating such paths on my own system, but I'd probably be better off intentionally setting up problematic folder names because you know someone out there has every crazy combination of characters the OS will support.