I saw somebody at work type the following commandline in Windows: start notepad blah.c He said "It's the easiest way to bring up a random file in Notepad."
Well, of course Wine should be able to do that, I realized when I woke up this morning, and I vowed to make it happen before I went to work today. So here's a quickie implementation of the start command. Seems to work... comments welcome. - Dan
On Thu, 16 Jan 2003, Dan Kegel wrote:
Well, of course Wine should be able to do that, I realized when I woke up this morning, and I vowed to make it happen before I went to work today. So here's a quickie implementation of the start command. Seems to work... comments welcome.
Shouldn't this be an internal wcmd command instead?
Dimitrie O. Paun wrote:
On Thu, 16 Jan 2003, Dan Kegel wrote:
Well, of course Wine should be able to do that, I realized when I woke up this morning, and I vowed to make it happen before I went to work today. So here's a quickie implementation of the start command. Seems to work... comments welcome.
Shouldn't this be an internal wcmd command instead?
You might think so, but on WindowsMe at least, it's a separate executable, C:\windows\command\start.exe
On Thu, 16 Jan 2003, Dan Kegel wrote:
You might think so, but on WindowsMe at least, it's a separate executable, C:\windows\command\start.exe
Indeed, but I'm a bit worried of poluting the Unix command line namespace with such a Windows specific feature...
With your command, what's the difference between
start prog
and
prog &
?
If I'm using bash, I expect Unix-like behaviour. I only expect Windows behaviour if I use wcmd. So maybe we can keep it as a separate program, but install it in a different path that's searched by default only in wcmd? Say $prefix/wine/bin? Or $prefix/bin/wine? What does FHS say, if anything?
Dimitrie O. Paun wrote:
You might think so, but on WindowsMe at least, it's a separate executable, C:\windows\command\start.exe
Indeed, but I'm a bit worried of poluting the Unix command line namespace with such a Windows specific feature...
With your command, what's the difference between
start prog
and
prog &
Easy: "prog &" doesn't look for the program in App Paths like start does. Also, once I make sure "start datafile" works, that will let you open the file with the appropriate windows app much easier than remembering the path to the program.
If I'm using bash, I expect Unix-like behaviour. I only expect Windows behaviour if I use wcmd. So maybe we can keep it as a separate program, but install it in a different path that's searched by default only in wcmd? Say $prefix/wine/bin? Or $prefix/bin/wine? What does FHS say, if anything?
I'd be ok with a wine bin, but I don't think FHS or LSB define a program called "start", so there's not much chance of clash if we install 'start'. And 'start' is *very* handy.
(And we already have a clash ... should we rename programs/view to not clash with vi's view alias, or is 'view' specified by windows?) - Dan
Dan Kegel dank@kegel.com writes:
I'd be ok with a wine bin, but I don't think FHS or LSB define a program called "start", so there's not much chance of clash if we install 'start'. And 'start' is *very* handy.
(And we already have a clash ... should we rename programs/view to not clash with vi's view alias, or is 'view' specified by windows?)
'view' is not installed in /usr/bin, and 'start' shouldn't be installed there either, it's very likely to conflict with something else. Since we install the .exe.so in /usr/lib/wine it will be available from wcmd anyway, and you can run it directly from the Unix cmdline with 'wine start', which is acceptable IMO.
It conflicts with vim's view, /bin/view.
--- Alexandre Julliard julliard@winehq.com a écrit : > Dan Kegel > 'view' is not installed in /usr/bin, and 'start' shouldn't be
installed there either, it's very likely to conflict with something else. Since we install the .exe.so in /usr/lib/wine it will be available from wcmd anyway, and you can run it directly from the Unix cmdline with 'wine start', which is acceptable IMO.
===== Sylvain Petreolle spetreolle@users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259
"Don't think you are. Know you are." Morpheus, in "Matrix".
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
Dan Kegel wrote:
I saw somebody at work type the following commandline in Windows: start notepad blah.c He said "It's the easiest way to bring up a random file in Notepad."
Well, of course Wine should be able to do that, I realized when I woke up this morning, and I vowed to make it happen before I went to work today. So here's a quickie implementation of the start command. Seems to work... comments welcome.
BTW, with this implementation, start notepad works, and start wordpad will probably work if you have the right registry entry (attached), but start foo.txt probably won't... I'll try it out, and maybe improve ShellExecute if needed.
Also, start takes a number of switches; I'll try to implement them soon. - Dan
Dan, It was already discussed when Dustin was trying to handle the autorun.inf files. If you want to do this, use cygstart. Could be funny if we merge it.
http://www.winehq.com/hypermail/wine-devel/2002/12/0279.html
BTW, with this implementation, start notepad works, and start wordpad will probably work if you have the right registry entry (attached), but start foo.txt probably won't... I'll try it out, and maybe improve ShellExecute if needed.
Also, start takes a number of switches; I'll try to implement them soon.
- Dan
-- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
REGEDIT4
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\WORDPAD.EXE] @="C:\Progra~1\Access~1\WORDPAD2.EXE"
===== Sylvain Petreolle spetreolle@users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259
"Don't think you are. Know you are." Morpheus, in "Matrix".
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
Sylvain Petreolle wrote:
Dan, It was already discussed when Dustin was trying to handle the autorun.inf files. If you want to do this, use cygstart. Could be funny if we merge it.
http://www.winehq.com/hypermail/wine-devel/2002/12/0279.html
Cygwin is GPL, but the registry-sensing changes have to go directly into ShellExecute, which is LGPL. Emulating them in start is not really an option. - Dan
Dan Kegel wrote:
Sylvain Petreolle wrote:
Dan, It was already discussed when Dustin was trying to handle the autorun.inf files. If you want to do this, use cygstart. Could be funny if we merge it.
http://www.winehq.com/hypermail/wine-devel/2002/12/0279.html
Cygwin is GPL, but the registry-sensing changes have to go directly into ShellExecute, which is LGPL. Emulating them in start is not really an option.
/me gets clue
I read the source for cygstart. It's at http://www.neuro.gatech.edu/users/cwilson/cygutils-package/cygutils-1.1.3.ta... It's also a thin wrapper around ShellExecute, just like my program, but they did put noticable work into that wrapper.
The license for Cygstart is GPL, and I'm afraid that may be a problem for merging. Would the leadership care to comment on whether individual directories in wine/programs can be under the GPL? - Dan
Dan Kegel wrote:
/me gets clue
I read the source for cygstart. It's at
http://www.neuro.gatech.edu/users/cwilson/cygutils-package/cygutils-1.1.3.ta... It's also a thin wrapper around ShellExecute, just like my program, but they did put noticable work into that wrapper.
The license for Cygstart is GPL, and I'm afraid that may be a problem for merging. Would the leadership care to comment on whether individual directories in wine/programs can be under the GPL?
- Dan
IANALBICCW1 (I am not a lawyer, but I can consult with one)
As far as I can see it, winelib apps that do not export any functionality don't have to be LGPL stricly, without affecting the usability of Wine elsewhere. Personally, I don't see why the DLLs themselves have to be LGPL, as we don't seem to dynamically link with them anywhere, but that is besides the point.
Shachar