I never had to use it since I never had anything complicated enough, but next time you relearn things, I've heard good things about ffmpeg-python [0] , it supports multiple inputs, outputs, custom filters, etc.
This just sounds like when the script is run, a lock is taken. It seems like a pretty fast and loose definition of "atomic" (as in, not the ACID sense), as it says below:
If a fatal error is returned, the channel program may have not executed at all, may have partially executed, or may have fully executed but failed to pass a return value back to userland.
If an external tool is allowed to acquire this kind of exclusive lock, I don't see the difference.
> If an external tool is allowed to acquire this kind of exclusive lock, I don't see the difference.
That's the whole point, as I understand it. The channel programs are executed in the kernel, in a way that cannot be done by external programs. Some more details here[1].
edit: I also think you should have included the note, which says
Note: ZFS API functions do not generate Fatal Errors when correctly invoked, they return an error code and the channel program continues executing.
So while it's not quite ACID-level, its not as bad as it sounds without that note.
My feeling is that they're already there with the command line (just look at the filter stuff). Might as well just go all the way and have something sane that's supported all over.
I find that ffmpeg's regular command lines are easier to mentally parse if I include additional \ to separate things out onto their own lines. That's what I've done in several shell scripts that do complicated things with ffmpeg, along with comment lines and echoing commentary on what it's doing to the terminal.
Their example from the readme:
Which turns into [0] https://github.com/kkroening/ffmpeg-python