From: asmwarrior <asm...@gm...> - 2011-02-14 14:25:19
|
Hi, any one has implement a gcc plugin on windows? I have asked on gcc mail list, but with no luck, no one answered. see: http://gcc.gnu.org/ml/gcc/2011-01/msg00401.html any one in mingw maillist have implement or try this? thanks. asmwarrior ollydbg from codeblocks' forum |
From: Ehsan A. <aza...@gm...> - 2011-02-15 22:23:59
|
On Mon, Feb 14, 2011 at 7:25 AM, asmwarrior <asm...@gm...> wrote: > Hi, any one has implement a gcc plugin on windows? > I have asked on gcc mail list, but with no luck, no one answered. see: > http://gcc.gnu.org/ml/gcc/2011-01/msg00401.html > > any one in mingw maillist have implement or try this? > > Isn't this feature what IDEs such as Eclipse (CDT) use for code completion? thanks. > asmwarrior > ollydbg from codeblocks' forum > > I wish I could be of any help, for the sake of all the fun I had with ollydbg years ago, good luck > > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list > etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Also: mailto:min...@li...?subject=unsubscribe > |
From: Asm w. <asm...@gm...> - 2011-02-16 01:23:38
|
On 2011-2-16 6:23, Ehsan Azarnasab wrote: > > > On Mon, Feb 14, 2011 at 7:25 AM, asmwarrior <asm...@gm... > <mailto:asm...@gm...>> wrote: > > Hi, any one has implement a gcc plugin on windows? > I have asked on gcc mail list, but with no luck, no one answered. see: > http://gcc.gnu.org/ml/gcc/2011-01/msg00401.html > > any one in mingw maillist have implement or try this? > > > Isn't this feature what IDEs such as Eclipse (CDT) use for code completion? no, CDT use it's own parser. Currently as I know, no IDE use GCC's parser for codecompletion. > > > thanks. > asmwarrior > ollydbg from codeblocks' forum > > I wish I could be of any help, for the sake of all the fun I had with > ollydbg years ago, good luck I'm not the author of "ollydbg debugger", I just use this as a forum ID. |
From: Chris S. <ir0...@gm...> - 2011-02-16 01:42:16
|
On 14/02/2011 9:25 AM, asmwarrior wrote: > Hi, any one has implement a gcc plugin on windows? > I have asked on gcc mail list, but with no luck, no one answered. see: > http://gcc.gnu.org/ml/gcc/2011-01/msg00401.html > > any one in mingw maillist have implement or try this? I think this post on the Cygwin mailing list holds true to MinGW gcc as well: http://cygwin.com/ml/cygwin/2011-01/msg00029.html Cheers! Chris |
From: Asm w. <asm...@gm...> - 2011-02-16 02:08:14
|
On 2011-2-16 9:42, Chris Sutcliffe wrote: > On 14/02/2011 9:25 AM, asmwarrior wrote: >> > Hi, any one has implement a gcc plugin on windows? >> > I have asked on gcc mail list, but with no luck, no one answered. see: >> > http://gcc.gnu.org/ml/gcc/2011-01/msg00401.html >> > >> > any one in mingw maillist have implement or try this? > I think this post on the Cygwin mailing list holds true to MinGW gcc as > well: > > http://cygwin.com/ml/cygwin/2011-01/msg00029.html > > Cheers! > > Chris thanks Chris for the info. So sad to hear that, I just think that if GCC(windows)can open the plugin interface, we can use GCC to generate some AST information. I'm not sure why the windows DLL structure are the the "limitation" of enable the GCC plugin feature under windows. Hopefully someone can port this feature to Windows. asmwarrior ollydbg from Codeblocks' forum |
From: Ehsan A. <aza...@gm...> - 2011-02-16 23:20:55
|
On Tue, Feb 15, 2011 at 7:06 PM, Asm warrior <asm...@gm...> wrote: > > On 2011-2-16 9:42, Chris Sutcliffe wrote: > > On 14/02/2011 9:25 AM, asmwarrior wrote: > >> > Hi, any one has implement a gcc plugin on windows? > >> > I have asked on gcc mail list, but with no luck, no one answered. see: > >> > http://gcc.gnu.org/ml/gcc/2011-01/msg00401.html > >> > > >> > any one in mingw maillist have implement or try this? > > I think this post on the Cygwin mailing list holds true to MinGW gcc as > > well: > > > > http://cygwin.com/ml/cygwin/2011-01/msg00029.html > > > > Cheers! > > > > Chris > thanks Chris for the info. > So sad to hear that, I just think that if GCC(windows)can open the > plugin interface, we can use GCC to generate some AST information. > > I'm not sure why the windows DLL structure are the the "limitation" of > enable the GCC plugin feature under windows. Hopefully someone can port > this feature to Windows. > Interesting, in "Eclipse->Project Options->C/C++ Build->Discovery Options" there is a line regarding gcc with invocation command "-E -P -v -dD ${plugin_state_location}/specs.c" I always assumed it has something to do with gcc plug-in feature. > asmwarrior > ollydbg from Codeblocks' forum > > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Also: mailto:min...@li...?subject=unsubscribe |
From: Asm w. <asm...@gm...> - 2011-02-22 07:07:18
|
On 2011-2-16 9:42, Chris Sutcliffe wrote: > On 14/02/2011 9:25 AM, asmwarrior wrote: >> Hi, any one has implement a gcc plugin on windows? >> I have asked on gcc mail list, but with no luck, no one answered. see: >> http://gcc.gnu.org/ml/gcc/2011-01/msg00401.html >> >> any one in mingw maillist have implement or try this? > > I think this post on the Cygwin mailing list holds true to MinGW gcc as > well: > > http://cygwin.com/ml/cygwin/2011-01/msg00029.html > > Cheers! > > Chris > > Today, I found more discussion on GCC devel, see here: http://thread.gmane.org/gmane.comp.gcc.devel/115392 it seems that currently windows plugin is not supported, hope it will supported in the future. |
From: Michael T. <my...@se...> - 2011-02-22 09:44:21
|
Hi all, I recently installed a new version of mingw. The MSYS bash looks differently now. More like a standard windows cmd.exe window. Why is this? Is there a way to switch back to the old "bubblegum" msys design? The biggest advantage was an easily resizeable window. I casn't do this with the new console design. I can only statically set the parameters in the properties of the window. Thanks. Michael |
From: LRN <lr...@gm...> - 2011-02-22 09:56:27
|
On 22.02.2011 12:44, Michael T. wrote: > Hi all, > I recently installed a new version of mingw. > The MSYS bash looks differently now. More like a standard windows cmd.exe window. > Why is this? Is there a way to switch back to the old "bubblegum" msys design? > The biggest advantage was an easily resizeable window. I casn't do this with the new console design. > I can only statically set the parameters in the properties of the window. > > Thanks. > > Michael > run msys.bat with `--rxvt' argument Before doing that, you'll need to run `mingw-get install msys-rxvt' I've been told that rxvt is not supported anymore, so do this at your own risk. |
From: Michael T. <my...@se...> - 2011-02-22 10:08:26
|
> > > run msys.bat with `--rxvt' argument > > Before doing that, you'll need to run `mingw-get install msys-rxvt' > > I've been told that rxvt is not supported anymore, so do this at your > own risk. Cann anyone please answer why is it no longer supported? And what are the possible risks? thanks. m. > ------------------------------------------------------------------------------ > Index, Search & Analyze Logs and other IT data in Real-Time with Splunk > Collect, index and harness all the fast moving IT data generated by your > applications, servers and devices whether physical, virtual or in the cloud. > Deliver compliance at lower cost and gain new business insights. > Free Software Download: http://p.sf.net/sfu/splunk-dev2dev > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list etiquette may > cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Also: mailto:min...@li...?subject=unsubscribe > > > |
From: Chris S. <ir0...@gm...> - 2011-02-22 11:56:31
|
On 22/02/2011 5:08 AM, Michael T. wrote: >> run msys.bat with `--rxvt' argument >> >> Before doing that, you'll need to run `mingw-get install msys-rxvt' >> >> I've been told that rxvt is not supported anymore, so do this at your >> own risk. > Can anyone please answer why is it no longer supported? As I understand it, upstream development has basically stopped for rxvt. > And what are the possible risks? I don't think there are any risks involved, you can use it at your discretion. Another option is mintty (available via 'mingw-get install mintty') which is an actively maintained terminal emulator that you can start via 'msys.bat --mintty'. Chris |
From: Keith M. <kei...@us...> - 2011-02-22 13:10:25
|
On 22 February 2011 11:56, Chris Sutcliffe wrote: > On 22/02/2011 5:08 AM, Michael T. wrote: >>> run msys.bat with `--rxvt' argument >>> >>> Before doing that, you'll need to run `mingw-get install msys-rxvt' >>> >>> I've been told that rxvt is not supported anymore, so do this at your >>> own risk. >> Can anyone please answer why is it no longer supported? > > As I understand it, upstream development has basically stopped for rxvt. That is part of the reason. >> And what are the possible risks? > > I don't think there are any risks involved, On the contrary: rxvt requires a pty I/O layer which simply doesn't exist on MS-Windows. MSYS emulates pty using pipes, but that introduces I/O buffering constraints, which really aren't compatible with expected pty behaviour. The result is applications which appear to have hung, (when really they are just stuck on a pending buffer flush). The workaround, which has often been suggested, is to sprinkle flush calls throughout the application's code, but IMO that really isn't a particularly satisfactory recommendation, (and may not even completely circumvent the issue). I know of at least one application, (groff), whose (non-interactive) build process locks up solid, (requiring to be forcibly aborted through task manager), when invoked under MSYS rxvt, yet it is perfectly well behaved in a regular Windows console. > Another option is mintty (available via 'mingw-get install > mintty') which is an actively maintained terminal emulator that you can > start via 'msys.bat --mintty'. I have never used this myself, but I understand that it too may be compromised by the lack of a functional pty I/O layer on Windows; (I may be wrong). A further option, (and this is my own preference), is http://sourceforge.net/projects/console/ We don't maintain or distribute this ourselves, but we do offer https://sourceforge.net/projects/mingw/files/MSYS/console/console-2.00b146-1/ to help you set it up, (although you may wish to grab a later release from the upstream project; if you do, you *will* need to modify the configuration, as in our setup script, since some of the defaults conflict with MSYS usage). -- Regards, Keith. |
From: Albrecht S. <vms...@go...> - 2011-02-22 13:55:25
|
On 22.02.2011 14:10, Keith Marshall wrote: > On 22 February 2011 11:56, Chris Sutcliffe wrote: >> As I understand it, upstream development has basically stopped for rxvt. > > That is part of the reason. > >>> And what are the possible risks? >> >> I don't think there are any risks involved, > > On the contrary: rxvt requires a pty I/O layer which simply doesn't > exist on MS-Windows. MSYS emulates pty using pipes, but that introduces > I/O buffering constraints, which really aren't compatible with expected > pty behaviour. The result is applications which appear to have hung, > (when really they are just stuck on a pending buffer flush). > > The workaround, which has often been suggested, is to sprinkle flush > calls throughout the application's code, but IMO that really isn't a > particularly satisfactory recommendation, (and may not even completely > circumvent the issue). Instead of using flush, it is also possible to set stdout and stderr unbuffered unconditionally at program initialization: setvbuf (stdout,NULL,_IONBF,0); setvbuf (stderr,NULL,_IONBF,0); Of course, a side effect is that the output is always unbuffered, even if really redirected to a file. >> Another option is mintty (available via 'mingw-get install >> mintty') which is an actively maintained terminal emulator that you can >> start via 'msys.bat --mintty'. .. or you can run it from a desktop shortcut with something like C:\MinGW\msys\1.0\bin\mintty.exe /bin/bash -l > I have never used this myself, but I understand that it too may be > compromised by the lack of a functional pty I/O layer on Windows; (I may > be wrong). Unfortunately you're right :-( but I like it anyway ;-) --- While we're at it (slightly OT): mingw-get suffers from this I/O buffering problem when run inside mintty. Could you imagine to "repair" this by using one of the techniques described above? Of course, there's the workaround to use a standard console when running mingw-get, but every now and then you forget this, and it's inconvenient. TIA for considering this... Albrecht |
From: Earnie <ea...@us...> - 2011-02-22 14:26:37
|
Albrecht Schlosser wrote: > > Instead of using flush, it is also possible to set stdout and stderr > unbuffered unconditionally at program initialization: > > setvbuf (stdout,NULL,_IONBF,0); > setvbuf (stderr,NULL,_IONBF,0); > > Of course, a side effect is that the output is always unbuffered, > even if really redirected to a file. > There are more issues besides the buffering. Pty should report itself as a console and can't since the emulation uses pipes. I wasted many hours into days trying to work around it and it isn't possible since MSYS doesn't control the native app. -- Earnie -- http://www.for-my-kids.com |
From: Michael T. <my...@se...> - 2011-02-22 14:18:03
|
> I know of at least one application, (groff), > whose (non-interactive) build process locks up solid, (requiring to be > forcibly aborted through task manager), when invoked under MSYS rxvt, > yet it is perfectly well behaved in a regular Windows console. So when I ran msys shell (let's say from the start menu) in the old versions an MSYS rxvt console was started. However, when I run msys in the latest version the console which is started is a pure Windows cmd shell? Doesn't seem that way to me, since commands like ls don't work in cmd.exe after the fresh mingw-get install. To sum it up - what is the difference between these three: standard windows cmd.exe console VS. latest msys console VS. the old msys rxvt console ? Michael |
From: Earnie <ea...@us...> - 2011-02-22 14:32:23
|
Michael T. wrote: >> I know of at least one application, (groff), >> whose (non-interactive) build process locks up solid, (requiring to be >> forcibly aborted through task manager), when invoked under MSYS rxvt, >> yet it is perfectly well behaved in a regular Windows console. > > So when I ran msys shell (let's say from the start menu) in the old versions an MSYS rxvt console was started. > However, when I run msys in the latest version the console which is started is a pure Windows cmd shell? > Doesn't seem that way to me, since commands like ls don't work in cmd.exe after the fresh mingw-get install. > To sum it up - what is the difference between these three: > standard windows cmd.exe console VS. latest msys console VS. the old msys rxvt console ? > A console isn't cmd.exe. The console is the window giving you stdin, stdout and stderr. So to that end cmd.exe uses a console, sh.exe uses a console, rxvt.exe is a terminal emulation wrapper to the console, mintty is a terminal emulation wrapper to the console. The terminal emulation wrappers cannot do the job they need to do because there is no method to perform PTY emulation on Windows. -- Earnie -- http://www.for-my-kids.com |
From: Michael T. <my...@se...> - 2011-02-22 14:46:40
|
> A console isn't cmd.exe. The console is the window giving you stdin, > stdout and stderr. So to that end cmd.exe uses a console, sh.exe uses a > console, rxvt.exe is a terminal emulation wrapper to the console, mintty > is a terminal emulation wrapper to the console. The terminal emulation > wrappers cannot do the job they need to do because there is no method to > perform PTY emulation on Windows. > Ok, so to be more specific: What's the difference between a cmd.exe and the *thing* one runs by clicking on a nice M icon with the text "MinGW Shell" next to it (installed with the latest mingw-get installer downloaded from official MinGW SourceForge website)? Michael |
From: LRN <lr...@gm...> - 2011-02-22 14:59:08
|
On 22.02.2011 17:46, Michael T. wrote: >> A console isn't cmd.exe. The console is the window giving you stdin, >> stdout and stderr. So to that end cmd.exe uses a console, sh.exe uses a >> console, rxvt.exe is a terminal emulation wrapper to the console, mintty >> is a terminal emulation wrapper to the console. The terminal emulation >> wrappers cannot do the job they need to do because there is no method to >> perform PTY emulation on Windows. >> > Ok, so to be more specific: > What's the difference between a cmd.exe and the *thing* one runs by clicking on a nice M icon with the text "MinGW Shell" next to it (installed with the latest mingw-get installer downloaded from official MinGW SourceForge website)? > > Michael > When you double-click cmd.exe, you run Windows Shell (the one that is able to interpret Windows Shell Commands And Scripts) in Windows Console. When you double-click on a nice M icon with the text "MinGW Shell" next to it (installed with the latest mingw-get installer downloaded from official MinGW SourceForge website), you run Bourne Again Shell (the one that is able to interpret *nix shell commands and scripts) in Windows Console. |
From: Keith M. <kei...@us...> - 2011-02-22 14:45:46
|
On 22 February 2011 14:17, Michael T. wrote: >> I know of at least one application, (groff), >> whose (non-interactive) build process locks up solid, (requiring to be >> forcibly aborted through task manager), when invoked under MSYS rxvt, >> yet it is perfectly well behaved in a regular Windows console. > > So when I ran msys shell (let's say from the start menu) in the old > versions an MSYS rxvt console was started. However, when I run msys > in the latest version the console which is started is a pure Windows > cmd shell? No. You are falling into the trap of confusing a console (terminal) with a shell. The two really are entirely independent concepts. > Doesn't seem that way to me, since commands like ls don't work in > cmd.exe after the fresh mingw-get install. > To sum it up - what is the difference between these three: > standard windows cmd.exe console Two entirely distinct concepts: cmd.exe is a shell; console is the container in which a shell, (or indeed any other application), may be run. On its own, console provides *absolutely* no shell functionality. > VS. latest msys console It *isn't* MSYS console; it *is* MS-Windows console -- a *container* window, in which we run bash.exe (sh.exe) as shell. > VS. the old msys rxvt console ? On its own, rxvt is no more than a container window; like MS-Windows console, it provides no shell functionality -- that comes from running bash.exe (sh.exe) within it. Same is true of mintty, and the alternate console app I recommend; these too are just containers; you need to run a shell within them, and that could just as well be cmd.exe or bash.exe This has all been explained before, in depth; please consult the archives for further details. -- Regards, Keith. |
From: Michael T. <my...@se...> - 2011-02-22 15:58:58
|
> This has all been explained before, in depth; please consult the > archives for further details. Thanks, I answered to Earnie's email before I received your answer. So please dismiss my other email. > > -- > Regards, > Keith. > > ------------------------------------------------------------------------------ > Index, Search & Analyze Logs and other IT data in Real-Time with Splunk > Collect, index and harness all the fast moving IT data generated by your > applications, servers and devices whether physical, virtual or in the cloud. > Deliver compliance at lower cost and gain new business insights. > Free Software Download: http://p.sf.net/sfu/splunk-dev2dev > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list etiquette may > cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Also: mailto:min...@li...?subject=unsubscribe > > > |
From: Mathias F. <M.F...@sc...> - 2011-02-22 14:58:13
|
Hi, On Tuesday 22 February 2011, Earnie wrote: > A console isn't cmd.exe. The console is the window giving you stdin, > stdout and stderr. So to that end cmd.exe uses a console, sh.exe uses a > console, rxvt.exe is a terminal emulation wrapper to the console, mintty > is a terminal emulation wrapper to the console. The terminal emulation > wrappers cannot do the job they need to do because there is no method to > perform PTY emulation on Windows. This thread points me to a question I was willing to understand for a long time. How is mintty or rxvt switched to raw input mode? On unix I will use tcsetattr with the apropriate setting of the ICANON flag. On a win32 console I use SetConsoleMode, alternatively I can get character input instead of line input using the _getch and kbhit functions. But on win32 using mintty or rxvt, I do have neither tcsetattr nor a win32 console. But I can see bash working on rxvt/mintty doing all the line editing stuff itself using readline - True!? How does this work? Thanks in advance Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 |
From: Andy K. <and...@gm...> - 2011-02-22 15:34:32
|
2011/2/22 Mathias Fröhlich: > > Hi, > > On Tuesday 22 February 2011, Earnie wrote: >> A console isn't cmd.exe. The console is the window giving you stdin, >> stdout and stderr. So to that end cmd.exe uses a console, sh.exe uses a >> console, rxvt.exe is a terminal emulation wrapper to the console, mintty >> is a terminal emulation wrapper to the console. The terminal emulation >> wrappers cannot do the job they need to do because there is no method to >> perform PTY emulation on Windows. > > This thread points me to a question I was willing to understand for a long > time. > > How is mintty or rxvt switched to raw input mode? > > On unix I will use tcsetattr with the apropriate setting of the ICANON flag. > On a win32 console I use SetConsoleMode, alternatively I can get character > input instead of line input using the _getch and kbhit functions. > > But on win32 using mintty or rxvt, I do have neither tcsetattr nor a win32 > console. > But I can see bash working on rxvt/mintty doing all the line editing stuff > itself using readline - True!? > > How does this work? Bash is an MSYS program, i.e. it's linked against the MSYS (née Cygwin) DLL. For such programs, everything works just as on Unix, i.e. they get working pseudo terminal (pty) devices, termios, readline, and all that stuff . MSYS vim and ssh also tend to be happier in rxvt or mintty than in the Windows console. Native Windows programs such as those built with the MinGW compiler, however, only see pipes where MSYS programs see ptys, with various unfortunate consequences: - isatty(stdin) returns false - stdout defaults to full buffering instead of line buffering - Calls to console-specific functions such as WriteConsole() fail The underlying issue isn't so much that Windows doesn't provide ptys, since Windows programs don't expect those anyway. The problem is that it doesn't provide an API that would allow 3rd party programs to impersonate a Windows console without resorting to console.sf.net's approach of grabbing the screen content from a hidden console window, which is still subject to many of the limitations of the console. Note besides: mintty and rxvt are not console wrappers. They're pty-based terminal emulators. Andy |
From: Mathias F. <M.F...@sc...> - 2011-02-22 15:58:09
|
Hi Andy, thanks so far for the explanation. On Tuesday 22 February 2011, Andy Koppe wrote: > Bash is an MSYS program, i.e. it's linked against the MSYS (née > Cygwin) DLL. For such programs, everything works just as on Unix, i.e. > they get working pseudo terminal (pty) devices, termios, readline, and > all that stuff . MSYS vim and ssh also tend to be happier in rxvt or > mintty than in the Windows console. Ok, the magic happens somewhere in msys.dll - ok, so far. But technically, the communication channel between mintty and the console application is still just a windows pipe which does not deliver direct tcsetattr support on that pipe. True? Sure, I can use the usual escape sequences to switch on an off echo for example by '\e[...'. But I was not able to find something like that to turn off input line editing in the terminal. And whatever example I was watching, there was a tcsetattr call that I was wondering how it communicates with minty over the plain windows pipe. So how does {msys,cygwin}.dll tell mintty about the executed tcsetattr call using that windows pipe? Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 |
From: Andy K. <and...@gm...> - 2011-02-22 17:10:05
|
2011/2/22 Mathias Fröhlich: > On Tuesday 22 February 2011, Andy Koppe wrote: >> Bash is an MSYS program, i.e. it's linked against the MSYS (née >> Cygwin) DLL. For such programs, everything works just as on Unix, i.e. >> they get working pseudo terminal (pty) devices, termios, readline, and >> all that stuff . MSYS vim and ssh also tend to be happier in rxvt or >> mintty than in the Windows console. > Ok, the magic happens somewhere in msys.dll - ok, so far. > > But technically, the communication channel between mintty and the console > application is still just a windows pipe which does not deliver direct > tcsetattr support on that pipe. True? Yes, but. Firstly, the DLL implements read() and write() on both sides of that pipe, so it could theoretically implement a protocol interleaving data and control information. That would make interoperability with non-MSYS programs even worse though, so it doesn't do that. Secondly, the DLL actually shares some memory between all MSYS processes, providing another communication channel. This is used for things like the mount table, the process table, and indeed the pseudo terminal devices including their termios flags. However, this isn't really relevant to your question either. > Sure, I can use the usual escape sequences to switch on an off echo for > example by '\e[...'. But I was not able to find something like that to turn > off input line editing in the terminal. > And whatever example I was watching, there was a tcsetattr call that I was > wondering how it communicates with minty over the plain windows pipe. > > So how does {msys,cygwin}.dll tell mintty about the executed tcsetattr call > using that windows pipe? The answer is: it doesn't. Line editing and the interpretation of all the other termios flags are implemented on the slave side of the pseudo terminal device. On Linux, that's done in the kernel; in MSYS, it's done in the DLL. Mintty never looks at any of that, apart from when it first creates the shell process, where it sets a few termios flags. After that, it just processes whatever comes in via read()s from the master side of the pty device, including any escape sequences. Remember it's emulating a terminal that would have been connected to the host via a plain ol' serial cable. Here's a good article explaining this stuff: http://www.linusakesson.net/programming/tty/index.php Andy |
From: Charles W. <cwi...@us...> - 2011-02-22 19:20:55
|
On 2/22/2011 9:45 AM, Keith Marshall wrote: > On 22 February 2011 14:17, Michael T. wrote: >> To sum it up - what is the difference between these three: >> standard windows cmd.exe console > > Two entirely distinct concepts: cmd.exe is a shell; console is the > container in which a shell, (or indeed any other application), may be > run. On its own, console provides *absolutely* no shell functionality. > >> VS. latest msys console > > It *isn't* MSYS console; it *is* MS-Windows console -- a *container* > window, in which we run bash.exe (sh.exe) as shell. Yep. In fact, the "console" is actually provided by CSRSS.EXE (Common Services Runtime Scripting Server) service (in Windows7, csrss further delegates to "conhost.exe" for this). This is entirely separate from the shell that is run inside it, cmd.exe. So, although it is hidden from most, the analogy is pretty good: csrss/conhost ~similar to~ rxvt,mintty,xterm,console.sf.net cmd.exe ~similar to~ bash,tcsh,... the latter runs inside the former. -- Chuck |