On Wed, Feb 2, 2011 at 1:52 AM, Vitaliy Margolen wine-devel@kievinfo.com wrote:
On 02/01/2011 09:47 PM, Albert Lee wrote:
On Sat, Jan 29, 2011 at 4:36 PM, Vitaliyvitaliy@kievinfo.com wrote:
-cd ~/.wine/drive_c/Program\ Files +cd .wine/drive_c/Program\ Files
This will break if current directory is not $HOME.
'cd' immediately precedes this.
That still doesn't make the command valid. It won't work from any directory, that's the point.
I meant 'cd' is the command preceding this one in the block this is a part of, if you look at the context. This is explaining how to navigate to the application's directory and run Wine. I wrote most of the original text for this section, FYI.
-/bin/sh -c glxgears +/usr/bin/env glxgears
What advantage does "env" has over full featured shell? This is unnecessary.
Why do you need a full shell to run a single external program? It complicates e.g. argument passing if you used this as a template.
Why do you don't want a full featured shell? What of that program is a shell script?
It's exec(2)'ed so it doesn't matter what the program is. That's the point of the interpreter specification.
-@="/bin/sh run_linx_program acroread "%1"" +@="/bin/sh -c "acroread `wine winepath -u '%1'`""
Have you actually tested this? This won't work for paths with spaces. If it will work at all.
Not with spaces, I'll fix this as well.
You still failed to test if it works. What "supposed to work" in shell doesn't mean it works in Wine's process exec. So please test your suggestions first. With Wine. And don't write shell scripts inside registry. That won't work or do what you think it "should".
It works perfectly fine, thank you. It's not parsed by Wine and none of the embedded characters are metacharacters for the registry. That's the reason for explicitly calling /bin/sh -c.
-Albert