[Bug 34730] New: Regresion : Wine can no longer execute unix programs
http://bugs.winehq.org/show_bug.cgi?id=34730 Bug #: 34730 Summary: Regresion : Wine can no longer execute unix programs Product: Wine Version: 1.6 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: cmd AssignedTo: wine-bugs(a)winehq.org ReportedBy: qparis(a)playonlinux.com Classification: Unclassified Since wine 1.6, it is impossible to run unix programs inside wine. - Step to reproduce : Run wine cmd /c /bin/ps (for example) The result expected is the result of the command "ps". Instead, wine gives an error and as a result, cannot run the program. The regresion test gave this commit : [dd0b719a3a1419f34774fc4cd921f3378d8c237b] cmd: Avoid infinite loop running batch program. Thank you ! -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=34730 Quentin Pâris <qparis(a)playonlinux.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |qparis(a)playonlinux.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=34730 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, regression Regression SHA1| |dd0b719a3a1419f34774fc4cd92 | |1f3378d8c237b -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=34730 Dmitry Timoshkov <dmitry(a)baikal.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|qparis(a)playonlinux.com | Summary|Regresion : Wine can no |Wine can no longer execute |longer execute unix |unix programs |programs | -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=34730 Dmitry Timoshkov <dmitry(a)baikal.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |us(a)edmeades.me.uk -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=34730 --- Comment #1 from Jason Edmeades <us(a)edmeades.me.uk> 2013-11-04 15:26:51 CST --- What is the use case for doing this? Obviously you cannot do this on windows, and reading the code and the change I made, it was purely by luck that it ever worked in wine's command anyway. In fact it didnt really work - if you try it, you'll see that it runs the unix program without waiting for it to complete, and gives you the command prompt back which is then overwritten by the programs output. If you assume the thing being run is a fully qualified unix path, its relatively easy to get this functionality back, I guess the question is whether we *should* add back in the functionality as there's little that can be done about the limitations. Attached is patch to get it working, but not sure it would be accepted if I submit it. It only supports a command in the form /path/to/unixexecutable -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=34730 --- Comment #2 from Jason Edmeades <us(a)edmeades.me.uk> 2013-11-04 15:27:56 CST --- Created attachment 46459 --> http://bugs.winehq.org/attachment.cgi?id=46459 Allow a command starting with a '/' to be a unix path and pgm Really adding it this time! -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=34730 Jason Edmeades <us(a)edmeades.me.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=34730 --- Comment #3 from Quentin Pâris <qparis(a)playonlinux.com> 2013-11-04 15:33:13 CST --- Hi, Thank you for responding. First of all, this feature is documented in your website. (http://wiki.winehq.org/FAQ#head-a2e0e85c30b3d9088d92f55bf8c783ebfefa7ce4) 7.4. How do I launch native applications from a Windows application? You can start native applications directly from Wine only if you specify the full path or use the shell: /usr/bin/glxgears or /bin/sh -c glxgears You might also need winepath to translate the filename from Windows format to Linux format (see next question). It can be very useful, for some programs. For example, in one of my app, I need to run java to do some tasks. Instead of installing java into a wineprefix, I can tell my app to run Linux's native jav. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=34730 Nikolay Sivov <bunglehead(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lovyagin(a)mail.com --- Comment #4 from Nikolay Sivov <bunglehead(a)gmail.com> --- *** Bug 35398 has been marked as a duplicate of this bug. *** -- 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.
http://bugs.winehq.org/show_bug.cgi?id=34730 --- Comment #5 from lovyagin(a)mail.com --- (In reply to comment #1)
What is the use case for doing this?
For example, I'm using Far Manager for most part of my work. It is very ofthen when I require to run some programs from its command prompt - open caja(nautilus) or linux terminal emulator or any other linux program to open file with (libreoffice/gimp etc).
Obviously you cannot do this on windows...
Obviously I can. I can any program installed on system from windows command prompt.
...and reading the code and the change I made, it was purely by luck that it ever worked in wine's command anyway.
Why? Isn't it normal reasonable behaviour to make no difference between linux and windows programs? Since I can run .exe file from linux command prompt (wine starts automatically), why I can't run any linux command from windows command prompt?
In fact it didnt really work - if you try it, you'll see that it runs the unix program without waiting for it to complete, and gives you the command prompt back which is then overwritten by the programs output.
It's OK. It would not wait on Windows too if you run winword from Far Manager. In fact the best way to develop this thing is to check weather console (wait) or X application (no wait) was executed and redirect output of console applications to wineconsole properly. It's acceptable but not a normal behaviour when executing program from Far manager causes to open new wineconsole windows each time. But removing any ability to execute linux program in non-acceptable at all.
If you assume the thing being run is a fully qualified unix path, its relatively easy to get this functionality back, I guess the question is whether we *should* add back in the functionality as there's little that can be done about the limitations.
Attached is patch to get it working, but not sure it would be accepted if I submit it. It only supports a command in the form /path/to/unixexecutable
Why only full path? Why? Everything that is valid linux command should be executed from wine shell. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=34730 oiaohm <oiaohm(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |oiaohm(a)gmail.com --- Comment #6 from oiaohm <oiaohm(a)gmail.com> --- If it was me I would close this bug. **Why only full path? Why? Everything that is valid linux command should be executed from wine shell.** In fact its not that simple. Linux commands use unicode most of the time or what is define by Linux Locale that might not be Windows application compadible. Windows commands don't all the time. So always auto running Linux command can in fact bring issues. ping in wine could be required to be different to ping in Linux. Also wine cmd ie wine shell is not a posix shell. So does not set up envorment as per posix standards. Lot of Linux native applications do expect a posix shell. /bin/sh -c {something} is to run a posix shell to setup a posix envorment. Yes not all Linux applications work with full path either from wine due to no posix envorment. **Since I can run .exe file from linux command prompt (wine starts automatically), why I can't run any linux command from windows command prompt?** This is binfmt_misc configuration of your distrobution. We don't recommend this been set in the first place. Since binfmt_misc can make it simple to run application as root in the first place. Yes it bad to be running wine applications as root. Far Manager for example running inside wine cannot see Linux permission correctly. There are other defects as well. The simple issue here N.L. you are doing something bad to start off with. I don't see that we should be making it simple for you todo this. Really you should be using something native to Linux like Midnight Commander. N.L. Quentin Pâris I have some big bad news on what you are talking about as well. Java applications using jini(platform native code) will explode if you pass Linux java at them. Some Java application will also explode if they get anything other than Windows paths. Yes automatically running Linux mono or linux java is a very big reason to kill off being able to run Linux applications directly from wine without having todo something special. Sorry most of the arguements to allow this come from people attempting or doing things that are not recommended. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=34730 --- Comment #7 from N.L. <lovyagin(a)mail.com> --- For me wine is a tool to run programs that are not ported to linux yet/have no normal linux analogues (Far Manager, indeed one of such a program). But for sure using of windows applications from linux should be reduced as much as possible for many reasons (speed, for example), so if there is a native linux program it should be executed instead of windows one. So I can't see any reason why I can't open office document using linux libreoffice from wine file explorer and not to install windows version of office to linux (in most cases not a very clever thing to do, isn't it?). (BTW I can't see any reason to open wine file explorer at all - it would be much better to open preferred native linux file explorer - caja/nautilus/dolphin etc). It is really very expected behaviour of wine shell to run linux application. Navigate to file in Far and run it by enter - why not? If it was not possible 5 years ago I probably would not migrate from windows to linux. At last that easily. Well, one last thing. If you type [code]ls.[/code] instead of [code]ls[/code] in the cmd shell the program would executed in the latest versions (probably z:\usr\bin should be in the wine %PATH%). Strange thing, isn't it? If you insist on removing the ability of executon of internal linux programs, why not to fix search of executable files without extension to make everything work properly? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=34730 Jerome Leclanche <adys.wh(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #8 from Jerome Leclanche <adys.wh(a)gmail.com> --- Confirmed by julliard, this is valid behaviour. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=34730 --- Comment #9 from Jason Edmeades <us(a)edmeades.me.uk> --- Jerome... Can you clarify what you mean by valid behaviour. The 'ls.' vs 'ls', or the fact we cant run linux programs after my change? My gut feeling is we should put in the patch I attached, which lets fully qualified unix paths work, but a random program you wish to run needs to be a windows suffix unless specified otherwise. Removing the auto suffixing (PATHEXT) would break windows compatibility. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=34730 --- Comment #10 from oiaohm <oiaohm(a)gmail.com> --- The issue is I wrap everything in shell scripts. There is no bug to us who do this. Jason Edmeades running Linux commands is still possible just far more strict. Yes you have to shell script them. Put the next two lines in a file. #!/bin/sh libreoffice "`wine winepath -u "$1"`" Apply chmod 700 so it has executable bit. Place this in a wine path. Yes I can do like c:\test.sh {some odf file }and it runs. It also gets more fun you can rename test.sh to test.exe or even libreoffice.exe. A shell script is not confused by wine with a elf binary that might be a elf.so or might not be. Yes it possible to make a more complex script that will allow libreoffice to be passed any number of arguements and function normally. Jason Edmeades my felling your patch should not be accepted. Linux applications don't expect or tolerate windows paths and can play up any how if don't have the posix envorment. There is something horible you have forgot Jason Edmeades with / to unix application what way is a UNC path. Yes either \\ or // or \/ or /\ is acceptable to be a UNC path under windows because windows treats / and\ as interchangable. So //somemachine/pathonthatmachine/win32.exe could be valid windows path to a windows executable not Unix/Linux/posix executable. You cannot sort by starting / alone. Jason Edmeades so mixing Posix and Windows style paths its going to cause trouble. Jason Edmeades for least trouble if anything is allowed from the linux would it should be shell something. N.L Shell script wrapping you can still call out to libreoffice and what ever native program you need. Difference is cleaner with possible command line filtering in script between windows applications and linux applications preventing the o my wrong directory type. Yes a Linux .sh file called from wine gives a clear seperation between windows style paths and Posix style ones. Direct calling without user having to think has been a error. N.L (BTW I can't see any reason to open wine file explorer at all - it would be much better to open preferred native linux file explorer - caja/nautilus/dolphin etc). Other than the fact windows programs cannot control Linux native programs properly. Yes a stack of windows application trigger a windows file manager to open then take control of it. So applications using caja nautilus dolphin... has to be done on is this compadible with applications running in wine case. N.L and Jason Edmeades the prior behavour was broken in the first place. It was breaking applications using UNC paths. Options. 1) Mandate shell scripts(yes FAQ needs update if this is the case). 2) Add a like a native.exe to wine. That basically says what is following native is a Linux/Posix/OS X command. /bin/sh stuff in the wine cmd shell simple dies never to return. This should also kill off people asking to straight run Linux programs all the time. Not allowing that IPC between windows and Linux is complete alien so Windows applications cannot talk properly to control Linux applications. Reality you wish to use a Linux program inside wine and have windows program work correctly you need a wrapper translating if it complex in the first place. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=34730 --- Comment #11 from Jerome Leclanche <adys.wh(a)gmail.com> --- (In reply to comment #9) Alexandre confirmed this is a valid bug, is what I meant. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=34730 Jerome Leclanche <adys.wh(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |major --- Comment #12 from Jerome Leclanche <adys.wh(a)gmail.com> --- Bumping to major since it's a regression on wine behaviour itself and a backwards-compatibility issue affecting lots of use cases. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=34730 --- Comment #13 from oiaohm <oiaohm(a)gmail.com> --- Jerome Leclanche "Bumping to major since it's a regression on wine behaviour itself and a backwards-compatibility issue affecting lots of use cases." Its also Windows Application Compadiblity issue. UNC paths and / acceptance under Windows. That windows applications are allowed to accept. Problem is I cannot see that the usage cases cannot be address by shell script wrappers so avoiding the UNC issues. Yes documentation update not a patch to wine. The question is it major code fix or major documentation fix. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=34730 --- Comment #14 from oiaohm <oiaohm(a)gmail.com> --- Bit more testing it is a problem I created under dosdevices unc\test\test\test.exe wine cmd /c '//test/test/test.exe' wine cmd /c '\\test\test\test.exe' Guess what both should work. Go back to versions of wine where direct running Linux commands work. Only 1 of those lines work. Both of those lines are valid under Windows. So prior versions of wine were in fact Windows application incompadbile. So what ever fix is done cannot break UNC. The current patch breaks UNC. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=34730 --- Comment #15 from oiaohm <oiaohm(a)gmail.com> --- Bit more testing it is a problem I created under dosdevices unc\test\test\test.exe wine cmd /c '//test/test/test.exe' wine cmd /c '\\test\test\test.exe' Guess what both should work. Go back to versions of wine where direct running Linux commands work. Only 1 of those lines work. Both of those lines are valid under Windows. So prior versions of wine were in fact Windows application incompadbile. So what ever fix is done cannot break UNC. The current patch breaks UNC. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=34730 --- Comment #16 from N.L. <lovyagin(a)mail.com> --- Well, I totally forgot about %PATHEXT% in Windows. I see, adding '.' to this variable makes 'ls' working too not only 'ls.'. So wine still can run linux programs (that's good), however current situation is not windows %PATHEXT% compatible at all - explicit extension typing executes linux program whether this extension is on %PATHEXT% or not. Creating shell scripts for linux program is generally a good idea but only for known and often used programs. Asking user to write a script for each new or one time used program is an evil thing. Anyway, if wine can execute linux scripts and programs with an extension, why it should not execute linux programs without extension? No standard sets that empty extension should be marked explicitly. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=34730 --- Comment #17 from Austin English <austinenglish(a)gmail.com> --- (In reply to comment #16)
Well, I totally forgot about %PATHEXT% in Windows. I see, adding '.' to this variable makes 'ls' working too not only 'ls.'. So wine still can run linux programs (that's good), however current situation is not windows %PATHEXT% compatible at all - explicit extension typing executes linux program whether this extension is on %PATHEXT% or not.
Creating shell scripts for linux program is generally a good idea but only for known and often used programs. Asking user to write a script for each new or one time used program is an evil thing. Anyway, if wine can execute linux scripts and programs with an extension, why it should not execute linux programs without extension? No standard sets that empty extension should be marked explicitly.
The bug is valid, as comment #8 points out. Further discussion isn't necessary. Talking about the bug won't fix it, patches will. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=34730 --- Comment #18 from oiaohm <oiaohm(a)gmail.com> --- Austin English if you dig back the patch that took this feature away was done to enable UNC to work and prevent other issues. And the patch here to reverse it then goes and breaks UNC. This is why there need to be discussion. native.exe written in sh is two lines. #/bin/sh ${@:1} I really don't see this is required to create a patch file this could be placed in documentation for those requiring the feature. Ok you might disagree with me on this point. ${@:1} is a really simple thing takes all the arguements the script was given removes the first 1 being the name of wrapper then executes. If the script is named native.exe placed in wine normal search path. "native.exe ls -l" or "native ls -l" works. "Creating shell scripts for linux program is generally a good idea but only for known and often used programs. Asking user to write a script for each new or one time used program is an evil thing." I guess you did not think a universal wrapper shell script is 2 lines. Is there anything wrong asking the user todo native first on native commands? Yes the smallest patch is implement a native.exe in bash and place it in the wine application search location. "Anyway, if wine can execute linux scripts and programs with an extension, why it should not execute linux programs without extension? No standard sets that empty extension should be marked explicitly." In fact it gets stranger than that. You will find chmod 700 shell scripts execute from wine without extention or .exe extention as well even with 1.6 and above. Why they don't detect as elf binaries. Windows sets that an executable will end in .exe. Windows also sets that no extention is unknown. The problem here is a in a valid windows application you can have the following. app.exe app As files. Attribute flags can be wrong guess what happens now when you allow execute without extention. This is the problem. Windows and Linux use different logic on what is executable. Linux/Unix world uses a solution called magic and executable bit http://linux.die.net/man/5/magic where you look at a file to work out if it executable or not. Windows world is using the extention. If something is flagged executable and its not the correct extention it still should not run under Windows. Now the problem here is how to make the two different standards play nice without blowing each others feet off. native.exe wrapper is the simplest. Since this creates a nice clear divide. My point of view is we cannot restore the functionality in its past form because the past form breaks stuff. We can add a new means todo the same kind of functionality. Ok wine "cmd /c /bin/ps" is never going to work again and most like should never of worked. But wine "cmd /c native /bin/ps" can be made work without breaking UNC or having windows applications execute wrong things. Is this change tolleratable. Really my last problem 2 problems is what should the application be named. native, winenat, winehost, winesh all come to mind. Final problem is should this be mainline or just documntation due to how simple the program to allow it is. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=34730 --- Comment #19 from oiaohm <oiaohm(a)gmail.com> --- #!/bin/bash ${@:1} Opps sorry typo I missed the all important ! and forgot that what I did there is a bashism. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=34730 Ken Sharp <imwellcushtymelike(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source -- 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.
http://bugs.winehq.org/show_bug.cgi?id=34730 Emmanuel Charpentier <emm.charpentier(a)free.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |emm.charpentier(a)free.fr --- Comment #20 from Emmanuel Charpentier <emm.charpentier(a)free.fr> --- Well ... I happen to have an "interesting" use case. Yes, it's a bit of a corner case, but it illustrates a general principle). I a bound to use Word 2003 (my employer's choice, alas...) for writing and maintaining scientific documents using not a few bibliographic references, whereas my main computing tools are unix-based. My bibliographic tool of choice is Zotero. Until now, I could fet away with Libreoffice and a few fixups. This is no longer the case : some paranoïd manager gets fits of pique when he sees an edit that has to be redone in Word and becomes (literally) unsufferable. Since I can't afford to hang him, I tried to use the Windows version of Zotero standalone along with Wine for my final edits. A solution has been found incrementally (see https://forums.zotero.org/discussion/12426/word-intergration-with-wine/#Item... from top to bottom) and needed a bit of patching of the solution offered by a previous reader. Now, I still have to do some cosmetic edits with Wird, but at least I can manage the references correctly. Okay, this works, but needs a second Zotero installation, that needs to be synchronized. Not fun (which means that in Real Life, "There Lie Tygers"....). The Zotero plugin for Word uses, at least un this patched version, command-line communication (yes, like unix plumbing !) between Word and Wndows-Zotero (it does it via VBA, of all things...). I tried to patch it by replacing the path to the Windows program by the path of the Linux program. No luck. Even a .exe symlink to the Linux program or oiaohm's "native.exe" trick fails (probably because, as noted by oiaohm in a previous post, the Linux Zotero's answer comes too late to be used). So I think a better solution is needed. My use case is probably a corner case, but I think there are lots of such "niche" application where this case of mixed-platform programming could be *extremely* useful. And this is something you can't do in a virtual machine (save for opening and maintaining an ssh tunnel : not fun to do under Windows...). So I'd like to see serious consideration given to this issue and a *correct* solution to this to be devised. Even if it can be felt this is a "new feature" request, the possibilities are ... interesting. -- 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=34730 jL <bugzilla(a)andamira.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bugzilla(a)andamira.net -- 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=34730 --- Comment #21 from Alexandre Julliard <julliard(a)winehq.org> --- As far as I can tell, the only thing you cannot do is run a command with no extension without adding '.' to PATHEXT first. This is the way it works on Windows too. Are there still other cases where running a Unix command fails, but running a binary of the same name would work on Windows? -- 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=34730 --- Comment #22 from Emmanuel Charpentier <emm.charpentier(a)free.fr> --- I saw Alexandre's answer. But I'm still unable to understand how I could lauch, for example, Linux's /usr/bin/iceweasel from either the command line or a VBA Call Shell() call. For example, from a "wine cmd" terminal, trying : start /unix /usr/bin/iceweasel gives me an error dialog box stating "Aucun programme Windows n'est configuré pour ouvrir ce type de fichier." (approximatively : "No Windows program is configured to open this type of file"). Similarly, in the same terminal, trying : start /unix /bin/ps gives me a blank line (no error), and gets back to the prompt. Trying : Z:\home\charpent>Z:\bin\ps is a bit more verbose : "Ne reconnaît pas « Z:\bin\ps » comme commande interne ou externe, ou fichier de commandes." (approximatively "Does not recognize Z:\bin\ps as an internal or external command or command file"). Maybe we should have an utility calling the system (Linux) shell and associate it with, for example the ".SH" exytension ? This would allow to create specific or generic shells invoking whatever Linux progfram we wish and communicate its outputs to Wine ? Note : I'm currently using Debian testing distribution, which is currently at at wine-1.8-rc4. Does this specific version has incompatibilities ? Any idea ? -- 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=34730 --- Comment #23 from Alexandre Julliard <julliard(a)winehq.org> --- (In reply to Emmanuel Charpentier from comment #22)
Maybe we should have an utility calling the system (Linux) shell and associate it with, for example the ".SH" exytension ? This would allow to create specific or generic shells invoking whatever Linux progfram we wish and communicate its outputs to Wine ?
If your script ends in .exe, you should be able to run it directly from the command line. If it ends in .sh, you have to add ".sh" to PATHEXT, and then it should run fine. If it has no extension, adding "." to PATHEXT should have the same result. As far as I can tell, this is exactly how Windows behaves. Do you see a different behavior? Note: start /unix uses a different code path, and probably behaves differently. This should be a separate bug, this bug is about cmd. -- 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=34730 --- Comment #24 from Emmanuel Charpentier <emm.charpentier(a)free.fr> --- (In reply to Alexandre Julliard from comment #23)
(In reply to Emmanuel Charpentier from comment #22)
Maybe we should have an utility calling the system (Linux) shell and associate it with, for example the ".SH" exytension ? This would allow to create specific or generic shells invoking whatever Linux progfram we wish and communicate its outputs to Wine ?
If your script ends in .exe, you should be able to run it directly from the command line.
Nope, as exemplified below [my comments between brackets] : charpent(a)asus16-ec:~$ ls -l .wine/drive_c/windows/system32/evince.exe lrwxrwxrwx 1 charpent charpent 15 Dec 27 17:13 .wine/drive_c/windows/system32/evince.exe -> /usr/bin/evince [ This is a symplink to the unix executable... ] charpent(a)asus16-ec:~$ ls -l .wine/drive_c/windows/system32/native.exe -rwxr-xr-x 1 charpent charpent 21 Dec 27 14:30 .wine/drive_c/windows/system32/native.exe charpent(a)asus16-ec:~$ cat .wine/drive_c/windows/system32/native.exe #!/bin/bash ${@:1} [ This is a shell script as suggested somewhere in the bug's discussion ) [ Let's try to use the symlink ] charpent(a)asus16-ec:~$ wine evince wine: Bad EXE format for C:\windows\system32\evince.exe. [ No such luck ... ] charpent(a)asus16-ec:~$ wine C:\\windows\\system32\\evince.exe wine: Bad EXE format for C:\windows\system32\evince.exe. [ It's not the path either : ] [ Let's try the shell script ] charpent(a)asus16-ec:~$ wine native ls -l wine: Bad EXE format for C:\windows\system32\native.exe. [ Nope. Let's check it's not a path problem : ] charpent(a)asus16-ec:~$ wine C:\\windows\\system32\\native.exe ls -l wine: Bad EXE format for C:\windows\system32\native.exe. [ No such luck. ] [ Check it again in a CMD.EXE session : ] charpent(a)asus16-ec:~$ wine cmd Microsoft Windows 5.1.2600 (1.8-rc4) Z:\home\charpent>evince Can't recognize 'evince' as an internal or external command, or batch script. Z:\home\charpent>native ls -l Can't recognize 'native ls -l' as an internal or external command, or batch script. [ Check for path problems : ] Z:\home\charpent>C:\windows\system32\evince.exe Can't recognize 'C:\windows\system32\evince.exe' as an internal or external command, or batch script. Z:\home\charpent>C:\windows\system32\native.exe ls -l Can't recognize 'C:\windows\system32\native.exe ls -l' as an internal or external command, or batch script. [ Not a path problem. I give up... ] Z:\home\charpent>exit
If it ends in .sh, you have to add ".sh" to PATHEXT, and then it should run fine.
Nope : charpent(a)asus16-ec:~$ mv .wine/drive_c/windows/system32/native.exe .wine/drive_c/windows/system32/native.sh charpent(a)asus16-ec:~$ wine cmd Microsoft Windows 5.1.2600 (1.8-rc4) Z:\home\charpent>set PATHEXT=.SH;%PATHEXT% Z:\home\charpent>echo %PATHEXT% .SH;.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH Z:\home\charpent>native ls -l Can't recognize 'native ls -l' as an internal or external command, or batch script. Z:\home\charpent>exit
If it has no extension, adding "." to PATHEXT should have the same result.
Nome : charpent(a)asus16-ec:~$ mv .wine/drive_c/windows/system32/evince.exe .wine/drive_c/windows/system32/evince charpent(a)asus16-ec:~$ wine cmd Microsoft Windows 5.1.2600 (1.8-rc4) Z:\home\charpent>set PATHEXT=.;%PATHEXT% Z:\home\charpent>echo %PATHEXT% .;.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH Z:\home\charpent>evince Can't recognize 'evince' as an internal or external command, or batch script. Z:\home\charpent>exit
As far as I can tell, this is exactly how Windows behaves. Do you see a different behavior?
Note: start /unix uses a different code path, and probably behaves differently. This should be a separate bug, this bug is about cmd.
Okay. Let's keep it simple and focused on CMD. It still does NOT work as advertized i the FAQ § 7.4... HTH, -- 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=34730 --- Comment #25 from Emmanuel Charpentier <emm.charpentier(a)free.fr> --- =============== E R R A T U M ! =============== There seems to be ONE and ONLY ONE way to invoke a Linux program on a Wine command line : charpent(a)asus16-ec:~$ ls -l .wine/drive_c/windows/system32/evince.exe -rwxr-xr-x 1 charpent charpent 26 Dec 27 17:41 .wine/drive_c/windows/system32/evince.exe charpent(a)asus16-ec:~$ cat .wine/drive_c/windows/system32/evince.exe #!/bin/sh /usr/bin/evince charpent(a)asus16-ec:~$ wine evince wine: Bad EXE format for C:\windows\system32\evince.exe. [ Doesn't work directly. Have to use the command interpreter ] charpent(a)asus16-ec:~$ wine cmd /c evince [ WORKS ! ] It seems to be valid from a cmd terminal : charpent(a)asus16-ec:~$ wine cmd Microsoft Windows 5.1.2600 (1.8-rc4) Z:\home\charpent>evince [ WORKS !] This is still different from what is advertised in the FAQ § 7.4... HTH, -- 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=34730 --- Comment #26 from Alexandre Julliard <julliard(a)winehq.org> --- You have to use cmd (or some other Windows application) to launch Unix binaries, yes. That's what the FAQ is about. The wine loader only supports loading Windows binaries, and there doesn't seem to be any need to change that. If you are running Unix binaries from Unix, there's no reason to go through the wine loader at all. -- 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=34730 --- Comment #27 from Emmanuel Charpentier <emm.charpentier(a)free.fr> --- (In reply to Alexandre Julliard from comment #26)
You have to use cmd (or some other Windows application) to launch Unix binaries, yes. That's what the FAQ is about.
So the FAQ § 7.4 should be rewritten to explain the exact procedure to use. The example given does *NOT* work currently.
The wine loader only supports loading Windows binaries, and there doesn't seem to be any need to change that.
There seems to be ssome corner-case counterexamples :
If you are running Unix binaries from Unix, there's no reason to go through the wine loader at all.
I am thinking of launching Linux bibaries from customizable but not recompilable Windows binaries (case in point : the Zotero plugin for Word, which (hopefully) can be modified to talk to a Linux Firefox binary...). -- 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=34730 Markus Kitsinger (SwooshyCueb) <root(a)swooshalicio.us> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |root(a)swooshalicio.us --- Comment #28 from Markus Kitsinger (SwooshyCueb) <root(a)swooshalicio.us> --- Have there been any changes since the last comment? -- 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=34730 hash <HASH.DuOrden(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |HASH.DuOrden(a)gmail.com --- Comment #29 from hash <HASH.DuOrden(a)gmail.com> --- I tested all variants used in comment #24 and in comment #25 with same result. (In reply to Alexandre Julliard from comment #26)
You have to use cmd (or some other Windows application) to launch Unix binaries, yes. That's what the FAQ is about.
The wine loader only supports loading Windows binaries, and there doesn't seem to be any need to change that. If you are running Unix binaries from Unix, there's no reason to go through the wine loader at all.
And maybe there isn't any reason but what about ping? We cannot use ping.exe to actually ping anything, we could use it with SELinux applied the right way, but even if some one created a reliable context that could be used with WINE, ping.exe still unable to take any advantage of that! -- 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=34730 Fabian Maurer <dark.shadow4(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4(a)web.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=34730 --- Comment #30 from Rosanne DiMesio <dimesio(a)earthlink.net> --- (In reply to Emmanuel Charpentier from comment #27)
So the FAQ § 7.4 should be rewritten to explain the exact procedure to use. The example given does *NOT* work currently.
If the documentation issue is the only reason this bug is still being kept open, that's been fixed. The relevant section of the FAQ is now 5.8, and it was rewritten some time ago to explicitly state the need to add a dot character to the end of the list of extensions in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment\PATHEXT (per comment 21). -- 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=34730 winetest(a)luukku.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |winetest(a)luukku.com --- Comment #31 from winetest(a)luukku.com --- (In reply to Alexandre Julliard from comment #26)
You have to use cmd (or some other Windows application) to launch Unix binaries, yes. That's what the FAQ is about.
The wine loader only supports loading Windows binaries, and there doesn't seem to be any need to change that. If you are running Unix binaries from Unix, there's no reason to go through the wine loader at all.
(In reply to Rosanne DiMesio from comment #30)
(In reply to Emmanuel Charpentier from comment #27)
So the FAQ § 7.4 should be rewritten to explain the exact procedure to use. The example given does *NOT* work currently.
If the documentation issue is the only reason this bug is still being kept open, that's been fixed. The relevant section of the FAQ is now 5.8, and it was rewritten some time ago to explicitly state the need to add a dot character to the end of the list of extensions in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment\PATHEXT (per comment 21).
I don't see that this is going to be changed. Suggesting closing this bug. -- 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=34730 Rosanne DiMesio <dimesio(a)earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #32 from Rosanne DiMesio <dimesio(a)earthlink.net> --- The bug was originally filed about the behavior of Wine, not the FAQ instructions, so marking WONTFIX per comment 26. -- 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=34730 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #33 from Austin English <austinenglish(a)gmail.com> --- Closing. -- 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)
-
wine-bugs＠winehq.org