seccomp
BUG: use /usr/bin/env python3
python may not exist, or could be the python 2 interpreter.
same should happen for tests.
Feel free to take over this PR, I just noticed this in passing.
coverage: 89.046%. remained the same when pulling 20cb26782af52fc08582ac1a74808f369d4bc640 on haampie:patch-2 into 2bc718995e782a8473ba9db8509a398ef69b2edc on seccomp:main.
Considering that Python v2 is long past it's EOL date, I'm wondering how much of an issue this is in practice, and would moving from "python" to "python3" end up creating more problems? Is there a Python requirement that systems have a working "python3" binary/link in addition to just "python"?
Python 3 itself installs python3 as an executable on unix systems, it does not install python.
For example on Ubuntu/Debian, python requires another package: https://packages.debian.org/sid/python-is-python3.
For example on Ubuntu/Debian,
pythonrequires another package: https://packages.debian.org/sid/python-is-python3.
It seems to be distro dependent. On my Arch system it appears the "python" package supplies both python and python3 whereas on Fedora (and presumably all Fedora/RHEL variants), python is supplied by the "python-unversioned-command".
It seems like there should be a PEP, or something similar, that defines a best practices for Python scripts. Digging a bit it seems like PEP-394 is relevant (see the "For Python runtime distributors" section).
Anyway, this looks fine to me and seems to be in keeping with the official Python guidance.
Acked-by: Paul Moore <[email protected]>
Anyway, this looks fine to me and seems to be in keeping with the official Python guidance.
Acked-by: Paul Moore <[email protected]>
Ooops, one more thing @haampie, could you provide a sign-off line in your commit?