Created attachment 193133 [details] RunApplication Crash - All parameters have been validated OK The RunApplication function in the ScritForge SF_Session component fails for unknown reason (see the attachment). Going step by step, the error is generated executing this instruction: oShell.execute(sCommand, Parameters, com.sun.star.system.SystemShellExecuteFlags.URIS_ONLY) I have copied the function in my IDE and modify simply the instruction as following: oShell.execute(sCommand, Parameters, URIS_ONLY) and it works... Thanks to investigate, Eric.
Could you attach a minimum example file so we can try to reproduce this?
Ok I gave a try on pc Debian x86-64 with master sources updated today and with LO Debian testing package 24.2.0.3 with this macro: Sub Main GlobalScope.BasicLibraries.LoadLibrary("ScriptForge") Dim session As Variant session = CreateScriptService("Session") session.RunApplication("/usr/bin/firefox") End Sub I don't reproduce a crash.
I gave a try on Windows with 7.6.5.2, I could reproduce the crash. However, if I change: oShell.execute(sCommand, Parameters, com.sun.star.system.SystemShellExecuteFlags.URIS_ONLY) to oShell.execute(sCommand, Parameters, URIS_ONLY) RunApplication still crashes.
On pc Debian x86-64 with master sources updated today, I could open gedit by using: session.RunApplication("/usr/bin/gedit") and after having changed SF_Session.xba oShell.execute(sCommand, Parameters, com.sun.star.system.SystemShellExecuteFlags.URIS_ONLY) to oShell.execute(Command, Parameters, com.sun.star.system.SystemShellExecuteFlags.DEFAULTS) I gave a try with this change on SF_Session.xba in Windows, it worked too. Of course if it's ok, we could get rid of these 2 lines: Dim sCommand As String ' Command as an URL sCommand = SF_FileSystem._ConvertToUrl(Command) but I prefer having more feedback since I hardly know ScriptForge.
It is a good catch, it is possible that when I just put URIS_ONLY without the full path, the DEFAULT option has been taken instead ...
Sorry forget my previous comment as I continued to use the URI format (did not comment the URI formatting line above). Here is my code: Set oShell = SF_Utils._GetUNOService("SystemShellExecute") sCommand = SF_FileSystem._ConvertToUrl(Command) ' --- Commented 'oShell.execute(sCommand, Parameters,com.sun.star.system.SystemShellExecuteFlags.URIS_ONLY) ' ----the one successfully executed oShell.execute(sCommand, Parameters,URIS_ONLY) Here is my Libreoffice version: Version: 7.6.5.2 (X86_64) / LibreOffice Community Build ID: 38d5f62f85355c192ef5f1dd47c5c0c0c6d6598b CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: fr-FR (fr_FR); UI: fr-FR Calc: CL threaded Regarding the context, I have just copied the RunApplication in my local application macros
In any case, a try/catch sequence should be probably added in this Runapplication function ... in case an invalid command is issued ...
(In reply to Eric Champy from comment #6) > Sorry forget my previous comment as I continued to use the URI format (did > not comment the URI formatting line above). > ... > ' ----the one successfully executed > oShell.execute(sCommand, Parameters,URIS_ONLY) >... Does it work for you with: oShell.execute(Command, Parameters, com.sun.star.system.SystemShellExecuteFlags.DEFAULTS) ?
Yes, it works if not using URI and DEFAULT ... oShell.execute(Command, Parameters, com.sun.star.system.SystemShellExecuteFlags.DEFAULTS) Command instead of "scommand" set from URI
Jean-Pierre: as you may have seen I've submitted https://gerrit.libreoffice.org/c/core/+/164968 Perhaps I missed something so prefer having some feedback.
I see in the attached image that the started file is a command file : .bat As described in https://help.libreoffice.org/latest/en-US/text/sbasic/shared/03130500.html?DbPAR=BASIC#bm_id3150040, there exists for the purpose of launching such a command a standard Basic built-in statement: Shell(). I would strongly advice to use this function in the actual context. Now, what about SF_Session.RunApplication() ? Read https://help.libreoffice.org/latest/en-US/text/sbasic/shared/03/sf_session.html?&DbPAR=BASIC&System=UNIX#RunApplication Its purpose is to launch - executable files or - user files that are launched by a specific application related to their file suffix (ex. open LO/Writer when suffix is .odt). I did not experience so far with RunApplication() any difference between ...URIS_ONLY and ...DEFAULTS. On this matter I would not change the code until further evidence that a change is necessary. Anyway the suppression of the sCommand variable and of the statement sCommand = SF_FileSystem._ConvertToUrl(Command) is strictly forbidden. The command must become an URL before beingused in the next statement while the input argument ("Command") may be given either as an URL or in OS native format.
(In reply to Jean-Pierre Ledure from comment #11) >... > Now, what about SF_Session.RunApplication() ? > Read > https://help.libreoffice.org/latest/en-US/text/sbasic/shared/03/sf_session. > html?&DbPAR=BASIC&System=UNIX#RunApplication > Its purpose is to launch > - executable files or > - user files that are launched by a specific application related to their > file suffix (ex. open LO/Writer when suffix is .odt). Just to know, do these commands work for you? on Linux: session.RunApplication("/usr/bin/gedit") on Windows session.RunApplication("c:\windows\system32\notepad.exe") ? Both of these are executable. > > I did not experience so far with RunApplication() any difference between > ...URIS_ONLY and ...DEFAULTS. On this matter I would not change the code > until further evidence that a change is necessary. > I saw the difference when I used "Command" instead of sCommand since I was stuck to launch the quoted 2 commands. > Anyway the suppression of the sCommand variable and of the statement > sCommand = SF_FileSystem._ConvertToUrl(Command) > is strictly forbidden. The command must become an URL before beingused in > the next statement while the input argument ("Command") may be given either > as an URL or in OS native format. Ok.
(In reply to Julien Nabet from comment #10) > Jean-Pierre: as you may have seen I've submitted > https://gerrit.libreoffice.org/c/core/+/164968 > Perhaps I missed something so prefer having some feedback. Just to share information with Eric, I abandoned the patch since it seems the wrong way to fix this.
(In reply to Julien Nabet from comment #12) > Just to know, do these commands work for you? > on Linux: session.RunApplication("/usr/bin/gedit") > on Windows session.RunApplication("c:\windows\system32\notepad.exe") > ? > Both of these are executable. > 1) on Linux - session.RunApplication("/usr/bin/kate") gives an error headed "KIO Client": For security reasons, launching executables is not allowed in this context. (*) - Shell("/usr/bin/kate") runs normally - session.RunApplication("/home/.../somefile.txt") opens the file in kate. - Shell("/home/.../somefile.txt") gives a Basic runtime error: File not found. 2) On Windows 10 - session.RunApplication("c:\windows\system32\notepad.exe") works well - session.RunApplication("c:\...\somefile.txt") opens the file in notepad++ :) - Shell("c:\windows\system32\notepad.exe") works well - Shell("c:\...\somefile.txt") gives a Basic runtime error: File not found. (*) Note that this error does not seem to be a LO error. "KIO" is some file management system shipped with KDE and Kubuntu (see https://github.com/KDE/kio).
Here are some additional explanations about my problem: (1) I want to invoke a java program from Calc, so I have created a DOS batch program that does the job (invoking that Java application, including path ) ... c:\users\...\mybatch.bat parm1 parm2 (2) This batch program has several parameters that I pass thru the RunApplication "Parameters" field (3) Here are the various results I did: ------- initial URIS ------------------------- KO 'sCommand = SF_FileSystem._ConvertToUrl(Command) 'oShell.execute(sCommand, Parameters, com.sun.star.system.SystemShellExecuteFlags.URIS_ONLY) See initial reporting - In any case an improvement is needed at least for error reporting - See the first attachment Investigation direction: see how parameters are managed through a URI command ------- Using DEFAULTS ----------------------- OK oShell.execute(Command, Parameters, com.sun.star.system.SystemShellExecuteFlags.DEFAULTS) ------- RunApplication replaced by SHELL ----- OK SHELL(Command,2,Parameters,True) Conclusion: in any case using SHELL is the best option, because it seems that the bsync option is mandatory in my case and I don't see such an option via RunApplication.. Thanks
I confirm that the tests described in comment#14 are independent of the flag com.sun.star.system.SystemShellExecuteFlags.DEFAULTS or ...URIS_ONLY. However I observe indeed too that session.RunApplication() can run a .bat file under Windows only when the DEFAULTS flag is applied. Also, there is a partial overlap between Shell() and RunApplication(). Specificities are: - Shell() launches more system applications and supports synchronous mode - RunApplication() starts applications from their associated user files My proposed actions: - make a patch that changes the flag to DEFAULTS (releases 24.8, 24.2, 7.6) - study if in case of error on the execute() statement a fallback on the Basic Shell() command is feasible, but probably only in asynchronous mode. Thanks for reporting the bug.
Jean-Pierre Ledure committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/065fa9d77e5bd550600e8985d7e7aac8e10745c4 ScriptForge (session).RunApplication() crash fix tdf#160222 It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Jean-Pierre Ledure committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/c826976b634596e476515a678ce415d9d16830c6 ScriptForge (session).RunApplication() crash fix tdf#160222 It will be available in 24.2.3. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Jean-Pierre Ledure committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/2b168309d077e0685fe0d90d2f84981845153f7c ScriptForge (session).RunApplication() crash fix tdf#160222 It will be available in 7.6.7. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Commit Notification from comment #18) > Jean-Pierre Ledure committed a patch related to this issue. > It has been pushed to "libreoffice-24-2": > > https://git.libreoffice.org/core/commit/ > c826976b634596e476515a678ce415d9d16830c6 > > ScriptForge (session).RunApplication() crash fix tdf#160222 > > It will be available in 24.2.3. > > The patch should be included in the daily builds available at > https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More > information about daily builds can be found at: > https://wiki.documentfoundation.org/Testing_Daily_Builds > > Affected users are encouraged to test the fix and report feedback. Agree, but I guess we should find a solution with URI that works in a non local context, specifically it there is a need to execute a REMOTE application...
(In reply to Jean-Pierre Ledure from comment #16) > My proposed actions: > - ... > - study if in case of error on the execute() statement a fallback on the > Basic Shell() command is feasible, but probably only in asynchronous mode. > RunApplication() encompasses both Shell() and SystemShellExecute.execute() with fallback from first to second when failure. Patch in 24.8: https://gerrit.libreoffice.org/c/core/+/165218
(In reply to Eric Champy from comment #20) > Agree, but I guess we should find a solution with URI that works in a non > local context, specifically it there is a need to execute a REMOTE > application... I'm afraid "URI" refers only to the file:// protocol in this context. Your demand is IMO out of the scope of the actual bug report. I suggest you to post a separate enhancement request.