I am fed up with resin slicers.
Chitubox is about as stable as a drunk on a tightrope, Lychee is bad for engineering models and over-priced if you just want some basic support functions and PrusaSlicer is under-developed. All of these solutions work for different things based on the goals of the user. (For some, Lychee is an excellent value so my distaste is likely not universal.)
What really pissed me off is that support painting shouldn't be a paid feature. You hold the mouse button down and drop a support at specific distance from the last. It doesn't take massive cloud computational clusters or huge storage requirements but yet, money. Fuck. That.
I want a completely FOSS tool that is stable and includes functionality for auto-positioning models and has a full set of knobs and levers for support generation, support painting included.
So, I spent the morning getting a dev environment setup for PrusaSlicer to use as a base for resin-only tools. Over the next month or so, I'll take some time to strip out all the FDM support and get the slicer into a bare-bones state with only the existing resin features. Of course, it'll be on GitHub.
Back to the main subject. I was hoping that y'all had references in regards to anything resin printing: Support placement methods, model rotation optimization, resin strength data, FEP peel force data or anything that could be coded and implemented into a slicer. Hell, even discovering different methods for hollowing an STL would be nice.
Data and strategies for various tools would be nice to have at this point to at least start forming a roadmap for development. (One of the first goals is to integrate UVTools as a snap-in, somehow.)
FDM tools are plentiful because of wide spread adoption. Resin printers still seem niche so printer manufacturers naturally gravitate to writing their own tools for their own hardware in their race to the bottom.
With all of that said, I am actually curious if others would even want to see a project like this kicked off.
There are about a million different flavors of how to download and execute a shell script. Regardless, you need to redirect the output of curl into bash with the -s flag. Bash needs to know that it is reading from STDIN.
Here is an over-thought stackoverflow page on it: https://stackoverflow.com/questions/5735666/execute-bash-script-from-url
Also, if the script is not being read properly, that might explain the dpkg lock issue. Running two instances of dpkg simultaneously is likely causing that collision you are seeing. (If one instance is running, it will touch a lock file and then delete it when it stops. It prevents "bad things" from happening when two instances of the same app want the same resources.)
That is odd if your path is broken. It curl should be in /usr/bin and 'which' should find it. Are you somehow launching another shell inside a shell? Like zsh inside of bash, or something in that flavor? (In some rare cases, that would break paths and profile configs for your active shell.)
Regardless of why curl isn't being found, or only partially found, or something, learn "env". You need to get a decent picture of what your working environment is and why something as basic as curl "isn't found". ('which' is about as a baseline of a command as there is.)