Process exe should not resolve symlinks + enhanced cmdline guessing

[GoogleCodeExporter]

This is both a bugfix and an enhancement.

THE BUGFIX

As explained here:
https://groups.google.com/forum/?fromgroups#!topic/psutil/oxAd0BuAzt0%5B1-25%5D
...the original exe gets resolved via os.path.realpath():

> Also, I heard a rumor that we tried to upgrade but couldn't because 
> .exe now follows hard-links on Windows. Earlier .exe would return the 
> path the process was started from, but now it returns the actual path 
> of the executable. Any idea where that behavior came from? Would it be 
> possible to expose both? 

This should be avoided and the original unresolved path be returned instead.
It is then up to the user to decide whether to resolve the path or not.

THE ENHANCEMENT

exe property is implemented such that if the original get_process_exe() call is 
not able to determine process executable we try to guess it from the cmdline.
get_process_exe() can raise AccessDenied tough, and we let that propagate 
immediately.
Instead we should:

- catch AccessDenied
- try to guess exe from cmdline as last resort
- if that didn't produce any result then raise AccessDenied

The test script below on Linux shows that by doing so we can determine twice 
the amount of exe(s) than before.
Similar results are likely to apply to other platforms as well.

found = 0
for p in psutil.process_iter():
    try:
        p.exe
    except psutil.AccessDenied:
        pass
    else:
        found += 1
print found

Both issues are now fixed in r1513 and r1514

Original issue reported on code.google.com by g.rodola on 14 Aug 2012 at 11:29

[GoogleCodeExporter]

Original comment by g.rodola on 16 Aug 2012 at 4:41

• Changed state: Fixed

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Updated csets after the SVN -> Mercurial migration:
r1513 == revision ???

Original comment by g.rodola on 2 Mar 2013 at 12:12