If you want this to be a little safer, instead of just those guardrails to prevent semicolons and such, you can split the command into an array of arguments, and use subprocess.Popen. It won't execute through a shell, so you don't have to worry about shell injection[1]. Though I'm sure there are unsafe ways to invoke ffmpeg anyway.
I'm pretty sure you can dump a stream without transcoding directly to a file, and the stream can be sourced from an url, and the destination file can be users ssh authorized_keys
And I am almost certain I could win $10M from a lottery ticket. I'm not worried about that actually happening though because it is statically never going to happen.
I'll start investing in the lottery right away, now that I know it is a sure thing. It is the difference between cumulative probability of all tickets sold (which would be 100%) versus and discrete probability of a single ticket (0.000000003 for Powerball, basically zero).
The cumulative probability of every `ffmpeg-english` command ever sent to OpenAI will likely be <5%, if not <1%, of all of the possible responses GPT-4 could give.
I really wish there was a native way to provide a suggested command to run next, and then let your own shell deal with it, after the user’s Enter keypress.
If you can make a python program which only uses stdlib, it becomes wonderfully portable and easy to work with. Also, significantly more people use stdlib, there is more knowledge on the internet, and xz-style supply chain attacks are significantly less likely.
This is why my advice to everyone is to use python's stdlib as much as possible, and avoid using Python's external libraries unless they significantly simplify code.
Plumbum seems nice (and also is packaged in debian/ubuntu, which is a plus), but it does not seem to be significantly safer than correctly written subprocess code, and it won't even save that much lines in this particular example.
I agree and disagree. Python’s Subprocess has been the reason for many unfortunate, time-consuming bugs among users who think they are properly executing external commands, but that in end cannot realize their logic are full of errors, with no indication that something went bad.
I agree that a standard interface is always better, however not at the cost of productivity. A better than the current Subprocess interface is needed, and I think plumbum is the direction to go.
I am curious which errors do you find most problematic? We have internal codebase with hundreds of developers, and we haven't observed many subprocess related bugs. And the ability to print command being executed (via shlex.join) so it can be copied to shell and debugged there is very nice.
That said, there is a bunch of rules in our internal style guide about this process, such as: avoid shell=True unless you need shell functionality and know how shell quoting works; use python instead of tools like grep/head/aws/etc.. when performance permits; check returncode after Popen calls; correctly quote ssh args (they are tricky!)
[1]: https://docs.python.org/3/library/subprocess.html#security-c...