https://bugs.documentfoundation.org/show_bug.cgi?id=159307
Stephan Bergmann <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|[email protected] |[email protected] | |desktop.org --- Comment #16 from Stephan Bergmann <[email protected]> --- Patrick, please don't take this the wrong way. We are all only trying to be helpful to each other, even if we sometimes fail at that and something might come across more negatively than it was intended. In comment 10, you identified the status quo regarding CertMgrPath set to an absolute system pathname (rather than just a basename, to be searched for in PATH) to be broken on all platforms. My commit from comment 12 tried to address that. I tested that commit also on macOS, where I observed that CertMgrPath set to either an absolute system pathname of an executable (e.g., "/usr/bin/true") or just a basename to be searched forin PATH (e.g., "true") now caused the intended executable to be run. I thus erroneously assumed this issue to be solved for good, and set it to FIXED. I failed to try on macOS with CertMgrPath set to the absolute system pathname of an application's directory (e.g., "/System/Applications/Clock.app"). That should now be addressed with my commit from comment 15. I also ignored the fact that the status quo in CertMgrButtonHdl is problematic with respect to any exceptions thrown from XSystemShellExecute::execute. Something that your proposed Gerrit change from comment 5 would address. I'd welcome it if you re-activated that change and do the relevant fixes. (And I'm un-attaching myself as assignee of this bug again.) What has to be noted, though, is the two modes of XSystemShellExecute::execute as described in the comment at <https://gerrit.libreoffice.org/c/core/+/162485/8#message-2321b00c23d361f3992f5e176a9dffb51698e056> "tdf#159307 XSystemShellExecute::execute() expects file URLs on macOS". What the code in CertMgrButtonHdl wants to do is run an executable, so it should use the non-URIS_ONLY mode with aCommand being a system pathname (as it does). If there are any issues with that mode, esp. on macOS (like the one I tried to address with my commit from comment 15), we should IMO try to address that in the XSystemShellExecute::execute code, not in the code that calls it. -- You are receiving this mail because: You are the assignee for the bug.
