http://bugs.winehq.org/show_bug.cgi?id=34730
--- Comment #18 from oiaohm oiaohm@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.