Yes, that would be more lightweight.

My bad. In KCoreAddons should should use tr()+arg() rather than i18n.

KIO doesn't have non-translated strings. It reimplements errorString() to combine the errorText (usually a path or URL) with a translated string based on the error code.
But the base KJob doesn't have any of that, it just defaults to errorText, so you *need* to use tr().

prepend const so begin/end below don't detach

I usually just use "/does/not/exist" as a path ;-)

This might actually be better because Windows has weird race conditions with the filesystem stuff.

KIO is designed like this for some reason, but I would just document the job constructor and let people create the job with new, outside KIO.

That's e.g. what akonadi does.

Emitting result twice would be a very bad idea, a KJob can only emit result once.

But QProcess can emit errorOccurred followed by finished (e.g. if the subprocess crashes, from what I can see in qprocess.cpp).
I think we want to only qWarning() in this method, and let lsofFinished take care of finishing the job.

const

The class would be slightly easier to use if this was a getter instead of a signal.

Because then, in a unittest, you can just do job->exec() and then job->processInfoList(), no spy needed.
In (GUI) application code you still need to connect to a signal, but then the usual KJob::result signal is enough, instead of two signals (processInfoAvailable in case of success, and result to handle failure).

See KIO::StatJob::statResult() for an example.

Signals emitted by jobs are useful if they happen during the job lifetime (e.g. progress signals). If they happen at the same time as result, then it's easier to use result as the notification signal.

The downside is one more member variable, but it'll be very short-lived so I wouldn't worry about memory usage.

(minor) we never check that new succeeded, in Qt code.

The reasoning is that on desktop systems, with swap enabled, before the swap is exhausted, the user will have given up and rebooted the machine anyway. I know I do, many times a month :). So in practice, new can be considered to always succeed.

You can use qputenv, more portable (in case we ever enable this code on Windows), safer in terms of life cycle of the strings (I mean in general, I know it isn't a problem here).

s/has/have/

[is it useful to repeat that sentence? I admit I'm no expert on Doxygen's @brief command]

has -> have (plural)

Return by value rather than by const ref. Otherwise it makes it hard to one day write something like

if (someCondition)
    return KProcessInfoList();
return m_processInfoList;

The cost of increasing/decreasing a refcount is negligible, especially in code that starts a secondary process :-)

+ don't forget to document the method

Inconsistent: two member variables have a trailing '_', the others don't.

In KF5 code it's usual to either have no prefix, or have m_ as prefix (but never a suffix).

Won't be needed anymore once the getter returns by value :-)