Hi Albert, http://wiki.winehq.org/FAQ?action=diff&rev2=384&rev1=383 looks like it was a pretty big edit.
Try smaller ones, and try to do just one kind of change per edit.
On 01/29/2011 12:21 PM, Dan Kegel wrote:
Hi Albert, http://wiki.winehq.org/FAQ?action=diff&rev2=384&rev1=383 looks like it was a pretty big edit.
Try smaller ones, and try to do just one kind of change per edit.
That, and the fact that some changes where questionable, and broken:
-cd ~/.wine/drive_c/Program\ Files +cd .wine/drive_c/Program\ Files
This will break if current directory is not $HOME.
- You can also use double quotes, but you need two backslashes instead of one:
-{{{ -wine start "C:\Games\Tron\tron.exe" -}}}
Backslashes still have special meaning inside double quotes. So they should be escaped.
-/bin/sh -c glxgears +/usr/bin/env glxgears
What advantage does "env" has over full featured shell? This is unnecessary.
-@="/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.
Vitaliy
On Sat, Jan 29, 2011 at 4:36 PM, Vitaliy vitaliy@kievinfo.com wrote:
On 01/29/2011 12:21 PM, Dan Kegel wrote:
Hi Albert, http://wiki.winehq.org/FAQ?action=diff&rev2=384&rev1=383 looks like it was a pretty big edit.
Try smaller ones, and try to do just one kind of change per edit.
That, and the fact that some changes where questionable, and broken:
-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.
- You can also use double quotes, but you need two backslashes instead of
one:
-{{{ -wine start "C:\Games\Tron\tron.exe" -}}}
Backslashes still have special meaning inside double quotes. So they should be escaped.
Yes, I'll fix this.
-/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.
-@="/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.
-Albert
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.
-/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?
-@="/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".
Vitaliy.
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
On 02/02/2011 09:52 PM, Albert Lee wrote:
I meant 'cd' is the command preceding this one in the block this is a part of, if you look at the context.
Then you should remove that cd instead. Starting instructions from "go to your home directory" just to jump somewhere else doesn't make much sense.
It's exec(2)'ed so it doesn't matter what the program is.
Basically run in a shell. So you need an extra wrapper (env) why?
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.
Don't write programs inside registry, especially involving multiple expansions and output redirection. That's what the shell is for. Keep it there as a simple 2 line script.
Vitaliy.
On Thu, Feb 3, 2011 at 12:13 AM, Vitaliy Margolen wine-devel@kievinfo.com wrote:
On 02/02/2011 09:52 PM, Albert Lee wrote:
I meant 'cd' is the command preceding this one in the block this is a part of, if you look at the context.
Then you should remove that cd instead. Starting instructions from "go to your home directory" just to jump somewhere else doesn't make much sense.
The instructions were intended to give some context for users who might not be familiar with the ~ expansion.
It's exec(2)'ed so it doesn't matter what the program is.
Basically run in a shell. So you need an extra wrapper (env) why?
To handle PATH search, since Wine requires an absolute path. This is a common trick used for locating interpreters for e.g. Python as well.
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.
Don't write programs inside registry, especially involving multiple expansions and output redirection. That's what the shell is for. Keep it there as a simple 2 line script.
It's a fairly trivial one-liner as it is, and doesn't depend on fixed locations for a script which would typically live in a user's home directory.
-Albert
On Thu, Feb 03, 2011 at 11:17:39AM -0500, Albert Lee wrote:
?It's exec(2)'ed so it doesn't matter what the program is.
Basically run in a shell. So you need an extra wrapper (env) why?
To handle PATH search, since Wine requires an absolute path. This is a common trick used for locating interpreters for e.g. Python as well.
It does depend on 'env' being installed in a standard place! It is also rather a side effect of env's real purpose - sanitising the environment.
David
On Thu, Feb 3, 2011 at 12:32 PM, David Laight david@l8s.co.uk wrote:
On Thu, Feb 03, 2011 at 11:17:39AM -0500, Albert Lee wrote:
?It's exec(2)'ed so it doesn't matter what the program is.
Basically run in a shell. So you need an extra wrapper (env) why?
To handle PATH search, since Wine requires an absolute path. This is a common trick used for locating interpreters for e.g. Python as well.
It does depend on 'env' being installed in a standard place! It is also rather a side effect of env's real purpose - sanitising the environment.
Absolutely, and I'll admit that /usr/bin/env is not quite as universal as /bin/sh, but this is the second example after one that just uses the simple absolute path to the executable.
-Albert
On 02/03/2011 09:17 AM, Albert Lee wrote:
The instructions were intended to give some context for users who might not be familiar with the ~ expansion.
Then mention that if you must. "~" is used in number of other places in FAQ, and all over the net. Please keep it simple.
It's a fairly trivial one-liner as it is
Which will blow away most windows users who have no concept of expansions and redirections. You not writing developer's guide, you writing FAQ for clueless windows users who want Wine do what they need.
Vitaliy.
On Thu, Feb 3, 2011 at 9:49 PM, Vitaliy Margolen wine-devel@kievinfo.com wrote:
On 02/03/2011 09:17 AM, Albert Lee wrote:
The instructions were intended to give some context for users who might not be familiar with the ~ expansion.
Then mention that if you must. "~" is used in number of other places in FAQ, and all over the net. Please keep it simple.
I will add that, since we're not properly explaining it currently.
It's a fairly trivial one-liner as it is
Which will blow away most windows users who have no concept of expansions and redirections. You not writing developer's guide, you writing FAQ for clueless windows users who want Wine do what they need.
The existing implementation is not exactly transparent to new users either, and we're not attempting to explain in detail how it works. Instead, I am suggesting reducing the complexity of the solution, which also reduces the work for the user.
-Albert
On 02/05/2011 07:54 PM, Albert Lee wrote:
Instead, I am suggesting reducing the complexity of the solution,
Multiple expansions, redirections and use of xargs is hardly a simplification of a script with 2 parameters.
Again, we are not talking about advanced skills here. We talking about users who do not understand what expansion, redirection are. Let alone xargs.
In either case please don't add such complex scripts into FAQ. Keep it simple.
Vitaliy.
On Thu, Feb 3, 2011 at 18:17, Albert Lee trisk@forkgnu.org wrote:
The instructions were intended to give some context for users who might not be familiar with the ~ expansion.
Using {$HOME} would be more portable. The Bourne shell (/bin/sh) on Solaris (9/10 - OpenSolaris defaulted to ksh) doesn't support ~ (although csh, zsh, bash, tcsh, ksh and just about all the other bundled shells does, it sh is the default shell)
(Checkin proper quoting in case it contains spaces might be necessary..)
Gert
Correction: ${HOME}
On Sat, Feb 5, 2011 at 10:05, Gert van den Berg wine-devel@mohag.net wrote:
On Thu, Feb 3, 2011 at 18:17, Albert Lee trisk@forkgnu.org wrote:
The instructions were intended to give some context for users who might not be familiar with the ~ expansion.
Using {$HOME} would be more portable.
And using "${WINEPREFIX:-${HOME}/.wine}/dosdevices/c:/Program Files" should work correctly in any Wine setup (on a Bourne-compatible shell), including one using a custom WINEPREFIX. (But might be somewhat hard to follow for someone not familiar with the technicalities of the Bourne shell)
On Sat, Feb 05, 2011 at 10:14:07AM +0200, Gert van den Berg wrote:
On Sat, Feb 5, 2011 at 10:05, Gert van den Berg wine-devel@mohag.net wrote:
On Thu, Feb 3, 2011 at 18:17, Albert Lee trisk@forkgnu.org wrote:
The instructions were intended to give some context for users who might not be familiar with the ~ expansion.
Using {$HOME} would be more portable.
And using "${WINEPREFIX:-${HOME}/.wine}/dosdevices/c:/Program Files" should work correctly in any Wine setup (on a Bourne-compatible shell), including one using a custom WINEPREFIX.
Better still "${WINEPREFIX:-${HOME:?}/.wine}/dosdevices/c:/Program Files" which will generate an error if HOME isn't set.
David
On Sat, Feb 5, 2011 at 3:05 AM, Gert van den Berg wine-devel@mohag.net wrote:
On Thu, Feb 3, 2011 at 18:17, Albert Lee trisk@forkgnu.org wrote:
The instructions were intended to give some context for users who might not be familiar with the ~ expansion.
Using {$HOME} would be more portable. The Bourne shell (/bin/sh) on Solaris (9/10 - OpenSolaris defaulted to ksh) doesn't support ~ (although csh, zsh, bash, tcsh, ksh and just about all the other bundled shells does, it sh is the default shell)
Anyone using the original Bourne sh *interactively* is in for a world of pain anyway (speaking as someone who often had to before the ksh93 replacement). I think relying on tilde expansion can can be considered good practice for the interactive use case.
-Albert
On Sat, Feb 05, 2011 at 09:49:30PM -0500, Albert Lee wrote:
Anyone using the original Bourne sh *interactively* is in for a world of pain anyway (speaking as someone who often had to before the ksh93 replacement). I think relying on tilde expansion can can be considered good practice for the interactive use case.
I wouldn't rely on ~ expansion - not unless you detect that it has returned empty string. Although anyone using a system that doesn't support it (most likely Solaris's /bin/sh) will probably know how to avoid the problem, not knowing what is wrong is more problematical.
Adding a few 'sh' conditional substitutions to a script might show some people just how powerful the language is - especially if they have onely ever seen windows cmd.com .bat scripts.
I've seen some recent systems fail to expand ~ properly (for some definition of the word 'properly') most noticably cygwin on windoes 7.
David
On Sat, 5 Feb 2011 21:49:30 -0500 Albert Lee trisk@forkgnu.org wrote:
I think relying on tilde expansion can can be considered good practice for the interactive use case.
Tilde expansion doesn't work if there are quotes around the path, and if you search the forum, you will find instances of users who did not know that and didn't understand why they were getting "No such file or directory" messages.
$HOME is better because it can be used inside quotes, but what I have found to be most understandable to newbies is simply /home/user/ with a note telling them to substitute their username for user. (Yes, there are people who need to be told that. This is the level of technical knowledge you are writing for in the FAQ.)
I notice you reverted the changes after I addressed these issues, care to explain why?
On Tue, Feb 1, 2011 at 11:47 PM, Albert Lee trisk@forkgnu.org wrote:
On Sat, Jan 29, 2011 at 4:36 PM, Vitaliy vitaliy@kievinfo.com wrote:
On 01/29/2011 12:21 PM, Dan Kegel wrote:
Hi Albert, http://wiki.winehq.org/FAQ?action=diff&rev2=384&rev1=383 looks like it was a pretty big edit.
Try smaller ones, and try to do just one kind of change per edit.
That, and the fact that some changes where questionable, and broken:
-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.
- You can also use double quotes, but you need two backslashes instead of
one:
-{{{ -wine start "C:\Games\Tron\tron.exe" -}}}
Backslashes still have special meaning inside double quotes. So they should be escaped.
Yes, I'll fix this.
-/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.
-@="/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.
-Albert
On 02/02/2011 08:10 AM, Albert Lee wrote:
I notice you reverted the changes after I addressed these issues, care to explain why?
See my response from yesterday.
Vitaliy.
-
Albert Lee -
Dan Kegel -
David Laight -
Gert van den Berg -
Rosanne DiMesio -
Vitaliy -
Vitaliy Margolen