chris kcat wrote:
Not sure if this is the best place to bring this up, but I'm not sure it's "ready". The problem is it runs through the terminal the Wine was exec'd from. When Wine is run from the desktop manager's menu, or started in the background (eg. wine foo.exe &), if wcmd is subsequently exec'd, it will become completely unuseable since it has no input, and potentially no output, terminal. It then has to be killed through the kill or killall command.
Have you ever seen this be a problem in the real world?
To be "ready", wouldn't it need to open up its own terminal window for input and output in Wine's desktop space (eg. the virtual desktop if it's in use, or the standard desktop)?
No. That would destroy its usefulness in background applications. - Dan
On Sunday 02 July 2006 16:31, you wrote:
Have you ever seen this be a problem in the real world?
Yes. Start Progman, or some ther "shell" application, without an xterm (eg. through your WM or by running wine progman.exe &), then attempt to execute wcmd.exe (a standard operation I'd think, if you want to have a Windows shell running and subsequently want to get a Windows command line). You lose the ability to control wcmd, and can't kill it without manually running kill or killall on the process.
To be "ready", wouldn't it need to open up its own terminal window for input and output in Wine's desktop space (eg. the virtual desktop if it's in use, or the standard desktop)?
No. That would destroy its usefulness in background applications.
Wouldn't not doing it destroy its usefulness? If wcmd is supposed to act like Windows' cmd, then it should act like Windows' cmd, eg. opening its own console window in Wine's desktop space and running there. If it doesn't, it would lead to compatibility issues for programs that try to use a cmd.exe window itself since the behavior is different.
[wcmd needs to start a window.]
Have you ever seen this be a problem in the real world?
Yes. Start Progman, or some ther "shell" application, without an xterm (eg. through your WM or by running wine progman.exe &), then attempt to execute wcmd.exe (a standard operation I'd think, if you want to have a Windows shell running and subsequently want to get a Windows command line). You lose the ability to control wcmd, and can't kill it without manually running kill or killall on the process.
The case I care about most is: in cron, or ssh'ing in without X forwarding, use wcmd.exe to run a batch file.
We need to be able to support both cases.
However, I'm not sure we need to solve the case you are discussing any time soon. Users who want to do what you're describing can run 'wineconsole'. Eventually, yes, it'd be nice to teach our cmd how to do that without nuking the use case I'm most worried about. - Dan
On Sunday 02 July 2006 23:58, you wrote:
The case I care about most is: in cron, or ssh'ing in without X forwarding, use wcmd.exe to run a batch file.
We need to be able to support both cases.
How about leaving wcmd.exe alone (or renaming it to winecmd.exe), and wait on making cmd.exe until a replacement that behaves like Windows' cmd.exe, then? You can have both that way. I'm mostly concerned about apps and/or people that expect cmd.exe to behave like Windows' version, when Wine's wcmd.exe doesn't.
On 7/3/06, Chris chris.kcat@gmail.com wrote:
On Sunday 02 July 2006 23:58, you wrote:
The case I care about most is: in cron, or ssh'ing in without X forwarding, use wcmd.exe to run a batch file.
We need to be able to support both cases.
How about leaving wcmd.exe alone (or renaming it to winecmd.exe), and wait on making cmd.exe until a replacement that behaves like Windows' cmd.exe, then? You can have both that way. I'm mostly concerned about apps and/or people that expect cmd.exe to behave like Windows' version, when Wine's wcmd.exe doesn't.
What's wrong with wineconsole? A separate command prompt is opened that behaves like cmd.exe.
On Monday 03 July 2006 01:46, you wrote:
What's wrong with wineconsole?
wineconsole by itself doesn't seem to do anything, and using --help didn't work (and there seems to be no man page). Running 'wineconsole wcmd.exe' started a command prompt in the activating terminal just like wcmd.exe normally does, except the console output is forced to 80x25 output with no back buffer (Windows' cmd.exe can have a configurable-sized back-buffer and can be resized), and the error/fixme/trace's from the apps run from it are displayed improperly (I suppose because they end lines with \n, and in wineconsole's console it needs \r\n).
On 7/3/06, Chris chris.kcat@gmail.com wrote:
On Monday 03 July 2006 01:46, you wrote:
What's wrong with wineconsole?
wineconsole by itself doesn't seem to do anything, and using --help didn't work (and there seems to be no man page). Running 'wineconsole wcmd.exe' started a command prompt in the activating terminal just like wcmd.exe normally does, except the console output is forced to 80x25 output with no back buffer (Windows' cmd.exe can have a configurable-sized back-buffer and can be resized), and the error/fixme/trace's from the apps run from it are displayed improperly (I suppose because they end lines with \n, and in wineconsole's console it needs \r\n).
try 'wineconsole --backend=user wcmd.exe'. Works great for me.
On 7/3/06, Chris chris.kcat@gmail.com wrote:
On Sunday 02 July 2006 23:58, you wrote:
The case I care about most is: in cron, or ssh'ing in without X forwarding, use wcmd.exe to run a batch file.
We need to be able to support both cases.
How about leaving wcmd.exe alone (or renaming it to winecmd.exe), and wait on making cmd.exe until a replacement that behaves like Windows' cmd.exe, then? You can have both that way. I'm mostly concerned about apps and/or people that expect cmd.exe to behave like Windows' version, when Wine's wcmd.exe doesn't.
Window's cmd.exe run under Wine seems to do exactly what wcmd.exe currently does in that it runs in its original terminal without creating a new console window. Creating the console to host cmd.exe is likely ouside the scope of cmd.exe.
Also, running cmd.exe from within an instance of cmd.exe in Windows does not open a new console window--using an existing console, be it unix or dos, seems to be the right thing to do.
Thomas Kho
-
Chris -
Dan Kegel -
James Hawkins -
Thomas Kho