There should be a test for subprocess calls so that once all the strings have been cleaned up and turned into arrays, regressions do not occur. Also, this will be a handy tool to identify places where subprocess still needs to be cleaned up. See Bug 9342 for more info on this subject.
is this something like git grep subprocess?
It's a little more comprehensive than that. If we want to avoid the use of shell=True, there should be some way of tracking how often this is used. If not, then any efforts to clean this up will be competing with the slow influx of shell=True in new code. The goal is that we would like to avoid (whenever possible) unwieldy shell commands that could be prone to breaking. We currently don't have any check to see how many of these commands exist, and if that number is increasing. We'd like to be able to keep an eye on this going forward, but I don't know enough about our test infrastructure to know if there are any tools in place to do this currently. Do you know of a way we could keep an eye on this?
We currently have no static analysis extensions written, but adding a custom checker to pylint [1] should cover the case you're describing. Now that doesn't solve everything, it would still be required: 1. to have a defined codebase where to run this checker against (is it the entire poky repo? I don't think so.) 2. to have a regular execution scheduled for these types of checks, I would suggest the odd milestones (M1, M3) [1] https://pylint.readthedocs.io/en/latest/reference_guide/custom_checkers.html
Just found out that the pylint checkers will be run as a part of patchtest testing. Adding the dependency of the bug.
Moving this to M2 since I won't have time today to close this out.
Several patches for this have landed, any future work should be filed as a new bug with specific changes required.