Broken PostProcessing when script changes out-filename

[foreachthing]

Version

version_2.3.0-248-g9c568a543

Operating system type + version

Windows 10

Behavior

CGode file is first created in "c:\Users\USERNAME\AppData\Local\Temp.16312.gcode", instead of "save-as" location.

So, original "save-to" location is lost while post processing. This is most annoying!!!!

Got a Post Processing Script defined.

• Python script (creates backup and changes original)

  • "g:\dev\Slic3rPostProcessing\SPP-Python\Slic3rPostProcessor.py --xy;"
  • Does not work anymore
  • Does not create file in "save-as" location
  • "Failed starting the script g:\dev\Slic3rPostProcessing\SPP-Python\Slic3rPostProcessor.py --xy C:\Users\USERNAME\AppData\Local\Temp.17628.gcode, Win32 error: 193"

• C# script (copies and renames "save-as" gcode file)

  • "H:\dev\Slic3rPostProcessing\Slic3rPostProcessing\bin\Release\Slic3rPostProcessing.exe;"
  • Does not work anymore
  • "Copying of the temporary G-code to the output G-code failed. Maybe the SD card is write locked? Error message: The system cannot find the file specified"
  • Creates file "c:\Users\USERNAME\AppData\Local\Temp\000011_.16312.gcode", instead of "c:\temp\000011_OrignalFileName.gcode".

So, now all my post processing has gone down the drain....
How is post processing supposed to work nowadays?

[xorza]

@foreachthing are you sure your scripts were executing fine before my changes? It could be that your scripts were always producing errors, but previously file was saved in the temp dir, then copied onto SD card, and only then post-processed. So if your scripts were failing, you could not notice that.

Can you please send me some very basic script that reproduces your problem, I will try to fix that.

I also have windows, few postprocessing scripts and they all work fine in temp directory.

[foreachthing]

Yes, my scripts used to work flawlessly... :-/
here's one: https://github.com/foreachthing/Slic3rPostProcessing/blob/master/SPP-Python/Slic3rPostProcessor.py

Note, that I always create a backup. But that is not required and could be removed. That was for debugging, mainly.

I've been using this https://github.com/foreachthing/Slic3rPostProcessing/releases for years now and it began to fail yesterday after a new pull/build) .

[foreachthing]

@xorza how do you process the gcode file after post processing?
I can easily post-process the temp file (manually) but not automatically. PS throws around with exceptions. So, my scripts are working, just not handling the temp-dir well.
I need your advice on how to handle that, since I'm renaming the gcode files with counter prefix (I can never ever overwrite an existing gcode file; this gives me some kind of "version control").

[xorza]

@foreachthing from what I see https://github.com/foreachthing/Slic3rPostProcessing/blob/master/SPP-Python/Slic3rPostProcessor.py you actually overwrite the original file, and that is exactly how my scripts work.

Before my PR behavior was

1. save gcode file to the temp dir
2. copy it to the destination dir
3. run postprocessing script on the final file

My pr made it:

1. Save gcode to the temp dir
2. run postprocessing on the temp file
3. copy the temp file to the destination dir

If your scripts remove post-processed file, that is our problem. PS fails to copy it from the temp to the destination and throws an exception.
For version control purposes in your script I would recommend you to copy the input file to a backup with prefix. As far as I understand your script it does exactly this currently, I dont see where you do renaming with prefix.

[bubnikv]

@foreachthing I am not sure what you are doing with the script, but I suppose you want the final name of the file to make a backup. Should we add it to the environment variables of the script?

[foreachthing]

@bubnikv with my c# post processing scrip (pps) I create a file with a counter-prefix: some.gcode => 000123_some.gcode.
That way I don't have to worry about overwriting anything. No, I actually don't need a backup.

And then I need to do that "Cura-Move", because the way the Ultimakers 2 work.They have those clips on the build-plate to hold the glass plate in place. If PS slices, I cannot control the entry point and ever so often it happens that the nozzle crashes in the clip. So, first XY, then Z, not Z first! As discussed in #2931 and #4065. So it's quite crucial for me that the pps work.

@xorza

from what I see (...) you actually overwrite the original file, and that is exactly how my scripts work.

Maybe so, but PS failes to copy the gcode to the correct location. So, maybe I need to change my script to accommodate your workflow. Maybe you can show me your pps, so I can learn how it should work now?!

[foreachthing]

Ok! The Python-version works ... dude, I forgot to add the python path 😞 before the script path. A big DOH' on my part! Sorry to bother you!

But the C# script still fails:

I guess, it's because I change the filename.

[xorza]

Yeah current flow will fail if script renames the file. In my vision - it is the correct behavior, output filename should be exactly same which you specified after pressing 'Export G-code' button. I'm sorry that these changes broke you work, though.

Can you change your C# script to make a backup of the input file, then postprocess it and overwrite the original file? I can take a look at your script and try to help, if needed

[foreachthing]

@xoan, well, this renaming thing was the whole purpose of my script. I may have one print setting that prints ok, improve it save it again, without worrying about overwriting the previous file (and keep track of changes). Now I'm back to square one ...
Maybe you could integrate my renaming-thingy 😉

[xorza]

I try and change behavior so name of the temp file will have an incrementing numeric postfix

[xorza]

Other thing I can do: if any post-processing needed, I can make one more temp copy, that will be used for postprocessing

[foreachthing]

I try and change behavior so name of the temp file will have an incrementing numeric postfix

What exactly will that do to my filename at the final location?
If I could make another wish: I'd like my incrementing number zero-padded (6 digits should suffice. Example: 000123_some.gcode. After this many files I'm positive I can start at zero again 😉 ), because of sorting.
And as always: please make this optional!
Btw: This prefix makes it incredibly easy to select the correct file to print (at least on my UM2), all you need to remember is the incrementing number.

Backup file won't be necessary. I'll remove that "feature" soon. That was for debugging only.

[bubnikv]

@foreachthing I still don't understand your problem.

The post-processing script was always assumed to do the change in place. If it does not, then the OctoPrint integration would not work.

The situation now is the same as before, only the file is named with a temp name. If you need the final name, we may accommodate that somehow, maybe through an environment variable.

[bubnikv]

@xorza We are not going to integrate a one trick pony. I still don't understand why @foreachthing cannot adjust his script to the new behavior and what would be the minimal support from PrusaSlicer to enable that.

[foreachthing]

@foreachthing I still don't understand your problem.

I can tell :-)

The post-processing script was always assumed to do the change in place. If it does not, then the OctoPrint integration would not work.

I don't use OctoPrint, All I want to do is rename the output gcode file with a prefix counter -> 000123-some.gcode instead of some.gcode.

The situation now is the same as before, only the file is named with a temp name. If you need the final name, we may accommodate that somehow, maybe through an environment variable.

I have the final name. Not the issue at hand.

[...]. I still don't understand why @foreachthing cannot adjust his script to the new behavior and what would be the minimal support from PrusaSlicer to enable that.

Sure. If I can somehow rename my files after postprocessing!!

I can handle the new temp-file. Only the new way the temp files are being process leaves me standing in the cold.
As soon as I rename the (temp) gcode file, the "new way" cannot copy it back.
Again:

1. Export gcode from PS
2. Temp files is created
3. Post processing is working on temp file

• I rename the temp file from .12345.gcode to 000123.12345.gcode.

4. "New way of postprocessing" can't find my new file -> ERROR.

And I cannot rename the file AFTER it has been copied to the "save-to" location.

I hope that now everything is clear as mud ;-)

[bubnikv]

I hope that now everything is clear as mud ;-)

I think I understand your workflow. The ways of PrusaSlicer users are mysterious.

If you leave the original file there, you may create your new file and the original file will be copied. I don't think that having the final unmodified file copied somewhere (maybe to a temp directory?) is an issue.

[foreachthing]

The ways of PrusaSlicer users are mysterious.

Oh, come on! ;-)

If you leave the original file there, you may create your new file and the original file will be copied. I don't think that having the final unmodified file copied somewhere (maybe to a temp directory?) is an issue.

No, no issue except my new file will remain buried in %app-data% and the unmodified on my SD-Card. That way I lose the ability to use the save-as dialog - I'd need to hardcode something. It used to work soooo well...!

Could you pass the save-as path to the postprocessing script as an additional parameter? First parameter: the temp file, second parameter the "real" path.

[bubnikv]

Could you pass the save-as path to the postprocessing script as an additional parameter? First parameter: the temp file, second parameter the "real" path.

We can do that. I wonder whether that may break somebody's script. I just checked that we allow the "script" line to contain not just the script, but also its optional parameters. The G-code path is being appended to the end of the optional user's script parameters. If somebody counts the number of parameters, she/he may get surprised.

We can optionally save the name of the target G-code file into an environment variable. I am not sure which one is better.

[foreachthing]

... I wonder whether that may break somebody's script.

Nobody cared when merging the changes to store the gcode in the temp directory... why now?
Edit: 😉

I just checked that we allow the "script" line to contain not just the script, but also its optional parameters. The G-code path is being appended to the end of the optional user's script parameters. If somebody counts the number of parameters, she/he may get surprised.

Why? It just needs to be properly documented and if someone can create a post processing script, he/she can adjust the script for another additional parameter.

We can optionally save the name of the target G-code file into an environment variable.

I like this idea. That way one could choose what (optional) parameters are being passed.
And I can change my script (...) to copy my "correctly named file" to the output directory.

[bubnikv]

... I wonder whether that may break somebody's script.

Nobody cared when merging the changes to store the gcode in the temp directory... why now?

Because the person doing the merge (me) showed insufficient imagination of what could break (how people are using our software). We actually do care, even if it may not seem to.

[foreachthing]

We actually do care, even if it may not seem to.

This came across wrong. Should have used a ;-).

[bubnikv]

Implemented with cf32b56

Implemented extension of the G-code post-processor framework:

1) New environment variable SLIC3R_PP_HOST contains one of
   "File", "PrusaLink", "Repetier", "SL1Host", "OctoPrint", "FlashAir", "Duet", "AstroBox" ...
2) New environment variable SLIC3R_PP_OUTPUT_NAME contains the name
   of the G-code file including path (for SLIC3R_PP_HOST == "File")
   or a name of the file after upload to the host (PrusaLink, Octoprint ...)
3) The post-processing script may suggest a new output file name
   (likely based on SLIC3R_PP_OUTPUT_NAME) by saving it as a single line
   into a new "output name" temp file. The "output name" file name is
   created by suffixing the input G-code file name with ".output_name".

Please note that the G-code viewer visualizes G-code before post-processing.

Please test it.

[foreachthing]

@bubnikv, this looks promising!!! :-)

Questions:

1. The real filename (from save as... dialog) is stored in [SLIC3R_PP_OUTPUT_NAME] ? So I'd have to add [SLIC3R_PP_OUTPUT_NAME] as a parameter to the "Post Processing Script" textbox? Then the temp filename will be added as last parameter, correct?
2. I could then rename the temp file (i.e. .12345.gcode) to .12345.gcode.0001-OriginalFileName.gcode after the processing?

Thanks!

[lukasmatena]

@foreachthing

1. No. It is not a placeholder in PrusaSlicer. It is an environment variable that should be accessible from inside your script, maybe like this. I don't know Python though. Btw., all PrusaSlicer config options should be accessible this way too (e.g. SLIC3R_LAYER_HEIGHT, etc).

2. No. Do not rename the temp file, create a new text file named .12345.gcode.output_name with the required new name inside. You can use either name of the file or absolute path. PrusaSlicer will copy and rename the file for you.

Example shell script:

#!/bin/sh
FILENAME=$(basename "${SLIC3R_PP_OUTPUT_NAME}")
OUTPATH=$(dirname "${SLIC3R_PP_OUTPUT_NAME}")
echo "renamed_${FILENAME}" > "${1}.output_name"

The notification about the successful export still contains the old name, actually selected in the file dialog. That is too complicated to change. In fact, we may soon regret implementing this at all.

[foreachthing]

In fact, we may soon regret implementing this at all.

Then don't! Seriously! If it's a pain to maintain and prone to break other stuff ... remove it!

[foreachthing]

More questions:
How long does that environmental variable exist? I cannot debug my script with vs_code since there is no such variable!? Not even shortly after running PS export gcode. Not even while running post processing...
Other environmental variables can be read from (i.e. windir).

Output PS:

Temp file: c:\Users\___\AppData\Local\Temp\.15940.gcode

Output post processing script:
c:\Users\___\AppData\Local\Temp\000069_None.output_name
None should be 2-1_CHF_Standard.

Results in: c:\Users\___\Desktop\2-1_CHF_Standard.gcode. PS does not do its magic and rename it to c:\Users\fuerer_g\Desktop\000069_None.gcode, as expected (nevermind the missing envvar).

When can I delete *.output_name? I guess I cannot delete it when the script is about to finish?! So, I might need a Windows Task to remove such files daily, maybe?

[foreachthing]

My vote goes to: Revert that change.
Who does benefit from this change anyway?!

[DrLex0]

This is a royal pain to work around. My post-processing script may produce multiple additional files next to the gcode file. These now end up in a temp directory and are lost. I can fix that by detecting this SLIC3R_PP_OUTPUT_NAME env variable and if it exists, use its path instead of the input file path to determine where to put those additional files.

There are other problems however. The post-processing script can optionally be run inside a Windows WSL environment (or whatever they call the integrated Linux thing in WIndows these days). To do this, the user has to configure a simple batch script as the post-processing script in PrusaSlicer. This script then invokes the actual post-processing script through WSL. I haven't tested this, but I seriously doubt that the environment variables of the batch script will carry over to the WSL environment. If this new post-processing mechanism will be enforced, I will simply have to drop support for using the script through WSL.

Apparently the idea behind this change is that some people save their gcode files directly to SD cards or slow USB sticks or the like, and it isn't a terribly good idea to run post-processing scripts on those. If you really deem this a common use case, I would vote to make this new post-processing method optional so the old direct method can still be used. The new method may be the default for all I care, as long as there is some option that I can toggle inside the config bundle that I distribute with my post-processing script.

[sej7278]

we seem to have a lot of hacky workarounds and changes to PrusaSlicer and post-processing scripts due to this merge, which sounds like it was made to address an issue that could be fixed simply by a change in workflow: save locally

[bubnikv]

@DrLex0

I haven't tested this, but I seriously doubt that the environment variables of the batch script will carry over to the WSL environment.

Maybe you should try it first?

[bubnikv]

@DrLex0

I can fix that by detecting this SLIC3R_PP_OUTPUT_NAME env variable and if it exists

It should exist.

This is a royal pain to work around. Use its path instead of the input file path to determine where to put those additional files.

That does not sound as a "royal pain" to me.

What you are asking for is to add an additional logic, to maintain it, to test it, so that three people could make use of it, while 150 thousand users will just wonder why the checkbox is there.

[bubnikv]

@foreachthing

My vote goes to: Revert that change.
Who does benefit from this change anyway?!

The guy who provided the original pull request?

For each feature in PrusaSlicer there is somebody somewhere in the universe who will want it to work the opposite way. We cannot handle the exponential explosion.

[sej7278]

But so far the one guy who wants the PR is outvoted by those who would rather it stayed as it was, and that's just out of alpha testers

[bubnikv]

But so far the one guy who wants the PR is outvoted by those who would rather it stayed as it was, and that's just out of alpha testers

The problem is that those who are happy are keeping quiet. Only those unhappy are loud.

[foreachthing]

@bubnikv those who are happy are not post processing 😠
Those who are happy were happy before.
Please undo PR #6000 or make it optional.

[DrLex0]

@bubnikv

@DrLex0

I haven't tested this, but I seriously doubt that the environment variables of the batch script will carry over to the WSL environment.

Maybe you should try it first?

I have just tested it and unsurprisingly, none of the environment from the Windows BAT makes it to the Linux runtime.
My knowledge of Windows scripting is too limited to try to fix this⁠—I normally only use Windows for games. I have only added the WSL workflow on request from someone, and so far each time I had to update it, it has cost me hours of figuring things out and testing them. If this change makes it to the final release, I will simply drop the WSL method from my instructions and hope anyone still using it will be willing to switch to a native Perl runtime.

As @sej7278 says, 2.4.0 is not even out of alpha phase and you're already getting complaints due to this change. I'm probably not the only one who normally doesn't even look at alpha releases (I only investigated this because I was notified that things were broken about the post-processing scripts I distribute). Those three people (actually at least four if I look at who posted in this issue) are likely just the tip of the iceberg. It wouldn't surprise me if even more complaints will come rolling in when going beta, and yet more after the final release. Sure, you could try to carefully document this new post-processing system and its env var, but it will remain non-intuitive and there will always be people who don't read all the documentation.

[foreachthing]

@DrLex0: I'm trying to use Python to get it to work - but still fail in renaming the output-file. So much for "post" processing.
You can use something like this (import getenv first) env_slicer_pp_output_name = str(getenv('SLIC3R_PP_OUTPUT_NAME')), this will work in Windows - not tested with Linux; Should work the same, though.

[bubnikv]

@DrLex0

https://devblogs.microsoft.com/commandline/share-environment-vars-between-wsl-and-windows/

[bubnikv]

@DrLex0

BTW I don't understand your scenario. You receive a file name on the command line. You post process it and save it under the same name. IMHO you don't need access to $SLIC3R_PP_OUTPUT_NAME.

[sej7278]

@bubnikv maybe it would help if you could explain why you seem so against reverting the change? do you suspect the people who would benefit would outweigh those who would be inconvenienced; or is there another feature that is likely to rely on this that you're thinking of or somesuch?

would be nice if we had some way to do a community vote to get some sort of idea of the fallout when this goes final - or if more than one person would benefit from it. blog/forum post maybe?

[DrLex0]

@bubnikv

BTW I don't understand your scenario. You receive a file name on the command line. You post process it and save it under the same name. IMHO you don't need access to $SLIC3R_PP_OUTPUT_NAME.

https://github.com/DrLex0/FFCP-GCodeSnippets

The main purpose of the script is to produce an extra X3G file because that is the only format this type of printer accepts. Next to this, the script also works around #2210, and can invoke other scripts before it does the X3G conversion. It may produce additional extra files with warnings or debugging info in them, which are particularly useful to troubleshoot problems during post-processing. Therefore I would absolutely need the env var to create the additional files in the target location instead of the tmp dir.
I don't know how common it is to generate additional files during post-processing, but given that quite a few people have already reported their workflow breaking from this change in an alpha release, it may be not that uncommon.

Preserving the WSL workflow may be possible by fiddling with this WSLENV var or passing additional arguments, but so far the only real justification for why I would have to spend time on implementing and testing that, is apparently because someone doesn't want to wait longer when saving files directly to slow storage media. If there would be more solid arguments why this new post-processing system is the way to go, it wouldn't feel like a waste of time.

[foreachthing]

Add a configurable counter to the filename and I'll close this issue. This issue is going in circels anyway. One guy wants it, many others don't.
Please make a "direct" post-processing option. Thank you!.

[bubnikv]

If there would be more solid arguments why this new post-processing system is the way to go, it wouldn't feel like a waste of time.

About 3 and half, possibly 4 man days were already spent on this topic by Prusa Research developers. That is quite a lot for what it is worth and still counting. Frankly I am inclined to just remove the feature if this continues. We need our development resources to fix supports, improve path planning, implement variable width extrusion etc. I personally would really love to spend my time on geometric algorithms to apply my expertise where it is most worthy.

The primary issue I see is that you guys are misusing a "post processing script" for deployment purposes. We at Prusa Research have no way to know how people in the world are using or misusing some versatile or too versatile feature without collecting usage statistics, which is another risky proposition. We find out by the (mostly negative) feedback once we change something.

You certainly agree that running a post processing script on an SD card does not make sense. SD card is slow and wears out. Thus we have accepted a pull request that made sense to us. There were other reasons to rework how the post processing script is integrated: OctoPrint integration and "export finished" notifications. Both of these features should be aware of the final name of the G-code or whatever file name is being exported. Certainly one can come up with a nicer interface to call the script, possibly passing some of the parameters as the target file name on the command line, however our implementation strives to be backward compatible wrt. to the scenarios we expected.

I have discussed this topic with two other in house developers and we frankly don't know what would be the best solution. IMHO you could help yourself with the tools that we gave you, but you oppose, because it requires a bit of work from your side. Which is difficult to understand to me, because the post processing script is a "write once, run many times" task.

I am considering to add another "deployment script" that would only be called when exporting a G-code and not when sending to OctoPrint, but I am not yet convinced to do that. What seems to you a single liner is a burden that the development, testing
and documentation team need to maintain indefinitely and it is my duty as a project manager to oppose such unnecessary features.

[bubnikv]

Regarding integration of Perl post processing scripts on Windows, we support
https://github.com/prusa3d/PrusaSlicer/wiki/Running-Perl-post-processing-scripts-on-Windows-from-Slic3r-PE-1.42-and-newer
On Windows, there is even a piece of code that looks up this particular Perl installation when executing the Perl script, thus WSL is not needed. Just download that Perl package and unpack it where PrusaSlicer resides.

[foreachthing]

@bubnikv I agree to a certain degree.
It used to work to my liking and after a random PR it broke my script. I agree, that post processing on an SD is not optimal.

I agree that you should be doing what you're doing best. But also understand that I spent many, many, many hours to get my script back to work (https://github.com/foreachthing/Slic3rPostProcessing/blob/master/SPP-Python/Slic3rPostProcessor.py) which still does not - and I don't know why. --> "write once, run many times" does not apply in this case!

Back to my issue: I'm stuck with the renaming the temp file to my name-pattern. If you got some spare time (which is probably rare), please have a look at my script. Use in in PS: "C:\Program Files\Python39\python.exe" "c:\dev\Slic3rPostProcessing\SPP-Python\Slic3rPostProcessor.py" --xy --noback --filecounter;. It creates the desired empty file but PS fails to pick that up - also, PS does not delete it afterwards.

PS save as: c:\temp\RealFilename.gcode
PS out: c:\...\temp\.56248.gcode
my SPP in: c:\...\temp\.56248.gcode
my SPP out 1: c:\...\temp\00123_RealfileName.output_name, or c:\...\temp\00123_RealfileName.gcode.output_name
my SPP out 2: c:\...\temp\.56248.gcode // processed
PS out: c:\temp\RealFilename.gcode // not correctly processed

Expected: c:\temp\00123_RealFilename.gcode

[lukasmatena]

@foreachthing
I do not know Python nor have time to test it, so it is quite possible I'm misreading something but

psfile = ntpath.join(ntpath.dirname(sourcefile), str(counter) + '_' + getFileName(ntpath.basename(env_slicer_pp_output_name)) + '.output_name')
open(psfile, mode='a').close()

seems suspicious. I would expect something like

psfile = ntpath.join(sourcefile, '.output_name')
open(psfile, mode='a')
.write(str(counter) + '_' + getFileName(ntpath.basename(env_slicer_pp_output_name)))
.close()

You will probably have to pythonize the syntax and everything. The name of the file is the temp filename appended with .output_name, its contents is the desired new filename (and optionally path). I was hoping the shell script I provided long ago in #6042 (comment) would make it clear. This possibly explains both why the renaming doesn't work and why PrusaSlicer does not delete your file after reading from it.

[lukasmatena]

@foreachthing So I decided to test it after all and this works (tested with Python 2.7.12). Like I said, I don't know Python, there might be some (possibly serious) mistakes, but it illustrates what needs to be done.

#!/usr/bin/env python

import sys
import ntpath
from os import path, getenv

env_slicer_pp_output_name = str(getenv('SLIC3R_PP_OUTPUT_NAME'))
psfile = sys.argv[1] + '.output_name'
f = open(psfile, mode='w')
f.write(str(666) + '_' + ntpath.basename(env_slicer_pp_output_name))
f.close()

Post edited to correctly handle file extension.

[foreachthing]

@lukasmatena , I feel really stupid now. I didn't understand, that the new name should be content of the file with "output_name" suffix.
Now it works - I'll upload the script (and also close this issue) as soon as I'm done testing!

Thank you so much, Lukáš!

[foreachthing]

@KnatteAnka, in case you're interested: I've added a revers counter to my script.
https://github.com/foreachthing/Slic3rPostProcessing/tree/master/SPP-Python

[DrLex0]

Regarding integration of Perl post processing scripts on Windows, we support https://github.com/prusa3d/PrusaSlicer/wiki/Running-Perl-post-processing-scripts-on-Windows-from-Slic3r-PE-1.42-and-newer On Windows, there is even a piece of code that looks up this particular Perl installation when executing the Perl script, thus WSL is not needed. Just download that Perl package and unpack it where PrusaSlicer resides.

WSL is just one possible way to invoke my scripts, which can be convenient if it's already available because Perl and Python normally ‘just work’ inside a Linux environment. I do recommend to the average Windows users to simply install a Perl runtime instead.
The fix to preserve the environment variable in WSL proved to be a one-liner and it even automatically converts the path format between Windows and Linux:

set WSLENV=SLIC3R_PP_OUTPUT_NAME/up

Of course, as usual it took quite a while to figure out what this one-liner should be, and verify that it works and doesn't break in older versions.

It would make sense to add a “deployment script” config option that is intended for doing things with the gcode file after it has been processed.

[foreachthing]

for doing things with the gcode file after it has been processed.

Hence the name post processing. I'm outta here! 😁

@DrLex0 I have not tested it with Linux, but the Python's ntpath should translate Windows <=> Linux paths as well. Maybe even MacOS'.