From: Roumen P. <bug...@ro...> - 2008-04-22 20:59:14
|
I could not get bash to work under wine (0.9.24). The content of bin directory: $ ls bashbug bash.exe mount.exe msys-1.0.dll ps.exe sh.exe If executable is run for linux command prompt: $ wine bash.exe --help; echo $? 1 Also from wine command prompt: $ wine cmd CMD Version 0.9.24 ...\bin>bash.exe --help ...\bin> and command output nothing. With this version of wine work well many other programs. As example cross compiled "Hello World!" console program output as expected. I extract only downloaded packages for bash(msys) and msys on system. Should I install other packages to get it working ? Roumen |
From: Earnie B. <ea...@us...> - 2008-04-23 14:46:39
|
Quoting Roumen Petrov <bug...@ro...>: > > I extract only downloaded packages for bash(msys) and msys on system. > Should I install other packages to get it working ? > I don't think it works and I know of no one who is wanting to make it work. Why do you have reasons to do this anyway? Earnie |
From: Charles W. <cwi...@us...> - 2008-04-23 14:58:26
|
Earnie Boyd wrote: >> I extract only downloaded packages for bash(msys) and msys on system. >> Should I install other packages to get it working ? >> > > I don't think it works and I know of no one who is wanting to make it > work. Why do you have reasons to do this anyway? Short version: cross-compile for mingw targets, for packages that use libtool-2.2. There are workarounds, but... This came up here: http://lists.gnu.org/archive/html/bug-libtool/2008-04/msg00080.html There were several issues in that thread, but after those were all tracked down and corrected, Rouman got to the last step -- using the msys shell under wine to run the libtool wrapper script, which should exec the true target executable. But it didn't work. Further experimentation, http://lists.gnu.org/archive/html/bug-libtool/2008-04/msg00142.html showed that the problem seemed to be with msys bssh itself, under wine (or wine's handling of msys bash). -- Chuck |
From: Earnie B. <ea...@us...> - 2008-04-23 20:46:54
|
Quoting Charles Wilson <cwi...@us...>: > Earnie Boyd wrote: >>> I extract only downloaded packages for bash(msys) and msys on system. >>> Should I install other packages to get it working ? >>> >> >> I don't think it works and I know of no one who is wanting to make it >> work. Why do you have reasons to do this anyway? > > Short version: cross-compile for mingw targets, for packages that use > libtool-2.2. There are workarounds, but... > > This came up here: > http://lists.gnu.org/archive/html/bug-libtool/2008-04/msg00080.html > > There were several issues in that thread, but after those were all > tracked down and corrected, Rouman got to the last step -- using the > msys shell under wine to run the libtool wrapper script, which should > exec the true target executable. But it didn't work. > > Further experimentation, > http://lists.gnu.org/archive/html/bug-libtool/2008-04/msg00142.html > showed that the problem seemed to be with msys bssh itself, under wine > (or wine's handling of msys bash). > Here http://lists.gnu.org/archive/html/bug-libtool/2008-04/msg00144.html you mention pty emulation. We all know that's broken with regard to native children, right; and AFAIK it's broken in Cygwin too. Been a thorn in my side since I started with the PORT especially since I chose to use RXVT. Earnie |
From: Keith M. <kei...@us...> - 2008-04-24 00:00:33
|
On Wednesday 23 April 2008 21:46, Earnie Boyd wrote: > Here > http://lists.gnu.org/archive/html/bug-libtool/2008-04/msg00144.html > you mention pty emulation. We all know that's broken with regard to > native children, right; and AFAIK it's broken in Cygwin too. Been a > thorn in my side since I started with the PORT especially since I > chose to use RXVT. I gave up on RXVT long ago, simply because its broken pty emulation caused me too much grief. (And yes, I too found Cygwin's RXVT to be similarly broken; the difference is that Cygwin doesn't push RXVT as the default console). My current favourite, for use on the Win2K box, is Console-2: http://sourceforge.net/projects/console/ This seems to offer the best of both worlds, (RXVT and native console), and I can even configure it to start MSYS without using msys.bat at all, with options for *both* MinGW and MSYS-DVLPR configurations. I hesitate to suggest offering it as a default console for MSYS, because it has been set up to build with Visual Studio, and porting to MinGW looks like it might be a rather ambitious project; nevertheless, I think it is well worth a look. Regards, Keith. |
From: Charles W. <cwi...@us...> - 2008-04-24 00:53:17
|
Keith Marshall wrote: > I gave up on RXVT long ago, simply because its you mean MSYS's and cygwin's? rxvt does not emulate ptys, the underlying posix DLL does that. > broken pty emulation > caused me too much grief. (And yes, I too found Cygwin's RXVT to be > similarly broken; the difference is that Cygwin doesn't push RXVT as > the default console). Keith, you really don't have to jump in and trash rxvt Every. Single. Time. it is mentioned. Everybody already knows you don't like it. As the cygwin maintainer of rxvt, I'd appreciate it if, when you do trash it, you point out that the pty problem is NOT the fault of rxvt. ANY terminal emulator that links against the cygwin dll or the msys dll will use that DLL's pty emulation. And the culprit here is the failure of the posix DLLs to implement PTYs in a way compatible with native win32 apps -- like mingw gcc.) Anyway, rxvt has *nothing* to do with this thread, aside from the fact that Earnie mentioned it in passing. The problem in *this* thread, is invoking a (native) win32 executable on a linux box via wine. That executable itself is just a wrapper, that attempts to exec a posix shell (e.g. msys-bash) with a shell script argument. This was the original failure case. But the OP simplified it down to just invoking msys bash via wine. From the OP: > If executable is run for linux command prompt: > $ wine bash.exe --help; echo $? > 1 > > > Also from wine command prompt: > $ wine cmd > CMD Version 0.9.24 > > ...\bin>bash.exe --help > ...\bin> > and command output nothing. No rxvt involved. Might be the same underlying pty cause, though. On the other hand, I can run (msys) "bash.exe --help" from a regular WindowsXP cmd.exe and it works just fine. So maybe the problem is wine. But it sure isn't rxvt. -- Chuck |
From: Earnie B. <ea...@us...> - 2008-04-24 16:27:49
|
Quoting Charles Wilson <cwi...@us...>: > > No rxvt involved. > > Might be the same underlying pty cause, though. On the other hand, I > can run (msys) "bash.exe --help" from a regular WindowsXP cmd.exe and it > works just fine. So maybe the problem is wine. > I can do one better, even in rxvt, execute cmd.exe from bash and type help. > But it sure isn't rxvt. > Correct. Earnie |
From: Keith M. <kei...@us...> - 2008-04-27 08:41:14
|
On Thursday 24 April 2008 01:53, Charles Wilson wrote: > > I gave up on RXVT long ago, simply because its > > you mean MSYS's and cygwin's? rxvt does not emulate ptys, the > underlying posix DLL does that. > > > broken pty emulation > > caused me too much grief. (And yes, I too found Cygwin's RXVT to > > be similarly broken; the difference is that Cygwin doesn't push > > RXVT as the default console). > > Keith, you really don't have to jump in and trash rxvt Every. Single. > Time. it is mentioned. Everybody already knows you don't like it. Actually, I would like it, if it weren't crippled by its dependence on the flaky pty emulation, in the underlying Cygwin or MSYS DLL. I'm sorry if I've touched a raw nerve, Chuck. However, we still see complaints about vanishing output, or program `hangs', when users were expecting a prompt, so perhaps an occasional reminder is not completely redundant. > As the cygwin maintainer of rxvt, I'd appreciate it if, when you do > trash it, you point out that the pty problem is NOT the fault of > rxvt. ANY terminal emulator that links against the cygwin dll or the > msys dll will use that DLL's pty emulation. And the culprit here is > the failure of the posix DLLs to implement PTYs in a way compatible > with native win32 apps -- like mingw gcc.) That's as may be, but Joe User is unlikely to care about such detail; all he will perceive is that *MSYS* appears to be `hung', so he considers MSYS itself to be broken. If the problem disappears when he drops RXVT, then his perception shifts, and his finger of blame points instead to RXVT, even if the real culprit is at a lower level, in a shared library on which RXVT depends. This problem will likely be more noticeable with MSYS, than with Cygwin, simply because MSYS provides fewer applications which actually use its POSIX emulation layer. Thus, those who like to use it as a general purpose cmd.exe replacement will be much more heavily dependent on native Win32 applications than Cygwin users, and hence more likely to perceive the issue. For such users, the solution is to dispense with RXVT, and use a native console, (unless of course, they really want a challenge, and are willing to debug the defective pty emulation issue; only in this case, will they care that the issue isn't in RXVT itself, but in the underlying POSIX emulation DLL). Regards, Keith. |
From: Earnie B. <ea...@us...> - 2008-04-27 13:03:06
|
Quoting Keith Marshall <kei...@us...>: > For such users, the solution is to dispense with > RXVT, and use a native console, (unless of course, they really want a > challenge, and are willing to debug the defective pty emulation issue; > only in this case, will they care that the issue isn't in RXVT itself, > but in the underlying POSIX emulation DLL). > Ok, but you're off topic with regard to this thread which is what Chuck was more perturbed with. RXVT came up en passant and you jumped on the ditch the RXVT band wagon to blow your whistle. Earnie |
From: Earnie B. <ea...@us...> - 2008-04-28 11:24:42
|
Quoting Earnie Boyd <ea...@us...>: > > Quoting Keith Marshall <kei...@us...>: > >> For such users, the solution is to dispense with >> RXVT, and use a native console, (unless of course, they really want a >> challenge, and are willing to debug the defective pty emulation issue; >> only in this case, will they care that the issue isn't in RXVT itself, >> but in the underlying POSIX emulation DLL). >> > > Ok, but you're off topic with regard to this thread which is what Chuck > was more perturbed with. RXVT came up en passant and you jumped on the > ditch the RXVT band wagon to blow your whistle. > s/the ditch// I'm not sure what happened. I was probably distracted. Sorry for the noise. Earnie |
From: Keith M. <kei...@us...> - 2008-04-29 16:26:43
|
On Sunday 27 April 2008 14:02, Earnie Boyd wrote: > > For such users, the solution is to dispense with > > RXVT, and use a native console, (unless of course, they really want > > a challenge, and are willing to debug the defective pty emulation > > issue; only in this case, will they care that the issue isn't in > > RXVT itself, but in the underlying POSIX emulation DLL). > > Ok, but you're off topic with regard to this thread which is what > Chuck was more perturbed with. RXVT came up en passant and you > jumped on the ditch the RXVT band wagon to blow your whistle. No, that wasn't my intended purpose at all. It was you who brought RXVT into the discussion; my real purpose was, as an aside similar to your own, to indicate that I now consider Console-2 to be worthy of consideration as an alternative, (having previously said that it didn't seem mature enough -- it has improved enormously in the past twelve months). Yes, I agree that this really deserves a thread of its own, but it's something I don't wish to discuss in depth just now, on account of other pressures on my time. I've briefly stated why I don't think we should consider bundling it, as an RXVT alternative, but I do think users should be made aware of it, and given the opportunity to make their own assessment. Clearly however, it will not help to run MSYS applications, such as bash, under wine -- it is for native use on Win2K and later only. Regards, Keith. |