[Bug 56471] New: starting of native program with "start /unix ..." is broken
https://bugs.winehq.org/show_bug.cgi?id=56471 Bug ID: 56471 Summary: starting of native program with "start /unix ..." is broken Product: Wine Version: 9.5 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: andreas.franz(a)arcor.de Distribution: --- Since 9.5, "start /unix <native-command>" is broken. A "file not found" error is thrown. PATHEXT is set with added dot at the end. Everything works fine with winehq 9.0-9.4. regards, Andy -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56471 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |leslie_alistair(a)hotmail.com --- Comment #1 from Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> --- This doesn't just affect start /unix. Using ShellExecute with a unix path also fails. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56471 yshuiv7(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |yshuiv7(a)gmail.com --- Comment #2 from yshuiv7(a)gmail.com --- I am trying to figure out the best solution to this. ShellExecute used to throw the command at CreateProcess, which works as CreateProcess will start a native program if it finds it. But this is wrong because CreateProcess searches for executables differently from ShellExecute. After my MR ShellExecute searches for executables the right way and pass a fully path to CreateProcess. If I now need to add the ability of running native programs to ShellExecute, it would pollute FindExecutable and PathResolve as well. How widely is this particular functionality used? If it's just `start /unix` can we change `start` to use CreateProcess directly? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56471 --- Comment #3 from yshuiv7(a)gmail.com --- Is it enough to make sure ShellExecute("executable.") will file "executable", IIUC? A dot is appended to PATHEXT. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56471 --- Comment #4 from AndyF <andreas.franz(a)arcor.de> --- "A dot is appended to PATHEXT." see here https://wiki.winehq.org/FAQ#How_do_I_launch_native_applications_from_a_Windo... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56471 --- Comment #5 from Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> --- At the simplest solution, might be to detect the first / since Unix programs have to be a full path. So then by bypassing the search paths. Windows paths generally start with a drive letter. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56471 --- Comment #6 from yshuiv7(a)gmail.com --- I think this should fix it: https://gitlab.winehq.org/wine/wine/-/merge_requests/5400 Executing a file with a dot at the end should now start the unix program. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56471 --- Comment #7 from yshuiv7(a)gmail.com --- (In reply to Alistair Leslie-Hughes from comment #5)
At the simplest solution, might be to detect the first / since Unix programs have to be a full path. So then by bypassing the search paths.
Windows paths generally start with a drive letter.
unix paths are converted to NT paths before they get to ShellExecute, IIUC -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56471 l.inc(a)alice-dsl.de changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |l.inc(a)alice-dsl.de -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56471 AndyF <andreas.franz(a)arcor.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #8 from AndyF <andreas.franz(a)arcor.de> --- Fixed with WineHQ 9.8 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56471 --- Comment #9 from l.inc(a)alice-dsl.de --- In 9.8, the problem still persists for me. Can we re-open this ticket or should I create a duplicate? $ wine64 start /unix "/bin/sh" 0160:fixme:exec:SHELL_execute flags ignored: 0x00000100 0160:fixme:exec:SHELL_execute flags ignored: 0x00000100 0160:fixme:exec:SHELL_execute flags ignored: 0x00000100 0160:fixme:exec:SHELL_execute flags ignored: 0x00000100 0160:fixme:exec:SHELL_execute flags ignored: 0x00000100 0160:fixme:exec:SHELL_execute flags ignored: 0x00000100 0160:fixme:exec:SHELL_execute flags ignored: 0x00000100 0160:fixme:exec:SHELL_execute flags ignored: 0x00000100 0160:fixme:exec:SHELL_execute flags ignored: 0x00000100 0160:fixme:exec:SHELL_execute flags ignored: 0x00000100 Application could not be started, or no application associated with the specified file. ShellExecuteEx failed: Success. $ wine64 --version wine-9.8 (Staging) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56471 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|RESOLVED |REOPENED Resolution|FIXED |--- --- Comment #10 from Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> --- Reopening, as user reported not fixed. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56471 --- Comment #11 from AndyF <andreas.franz(a)arcor.de> --- In my case, executing an executable shell-script at wine's user-context works fine. Username: "andy", owner of the script: "andy",too. -> success Executing a binary-program like e. g. "bash" fails, though. Maybe it's at rights-thing? regards, Andy -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56471 KIL <kilenab937(a)nweal.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kilenab937(a)nweal.com --- Comment #12 from KIL <kilenab937(a)nweal.com> --- I'm in the same situation with a tool.exe that worked for years calling a linux script. My tool.exe reads the name of the script from an .ini file where it is set, then it checks that the file is preset and tries to exec it. (tool.exe, tool.ini, script.sh are all in the same folder) tool.ini: external_script="/usr/local/tool/script.sh" Until 9.3 it was working correctly. Now, with any build >= 9.5 and also latest master my tool.exe gives no error about file presence but does NOT executes it. If i rename the script, the tool correctly produces a warning about the missing file. THEN, the point. If I change the tool.ini, setting the script name WITHOUT the absolute path; external_script="script.sh" Now tool.exe executes it correctly. So, recent wine versions cannot execute external linux scripts when they are defined with full path! -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56471 Marek Kraus <gamelaster(a)outlook.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gamelaster(a)outlook.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56471 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56471 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Fixed by SHA1| |cef7d4f39700aee05c42a5932bb | |533731b70d949 Resolution|--- |FIXED --- Comment #13 from Alexandre Julliard <julliard(a)winehq.org> --- It should be fixed by cef7d4f39700aee05c42a5932bb533731b70d949. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56471 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #14 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 10.0-rc3. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla