On 2/10/2016 7:52 AM, Baruch Burstein wrote: > Based on the quotes in the last email, this conversation seems to be > going on in two separate places. I don't know where the second place is, > but this is confusing. Please consolidate.
You are right. I apologize. Obviously, the discussion has veered wildly from "gdb in msys". I tried to post this separately in the discussion. And thanks for your detailed response below. > As for the specific issue of running mc directly from the windows > command prompt, my findings on a Windows 7 machine are that mc, > presumably through ncurses, sizes itself to the window buffer width > rather than the actual width, to the actual window height, and does not > get window resize notifications. What this means is that if I size my > command prompt window to it's maximum width, mc looks fine. There are > still at least a couple of issues, specifically that changing the height > of the window does not in itself prompt a redraw of the screen (although > pressing a key after the resize fixes this). Also pressing and holding > an arrow key only moves down one line. running mc directly from the > mintty/bash prompt works fine. That's my same experience. In other words, mc works fine from within a windows 7 command prompt, with the exception that that windows resize does not immediately take effect, but requires pressing a key. > Now for the general issue discussed in this thread. > @Daniel, I would like to point out that you not understanding an > explanation is not a sign of the explainer's lack of understanding > himself. It could also be a sign of either a bad explanation, > language/communication issue, or in rare cases your own misunderstanding. > That said, I admit that I don't fully understand the issue, but here is > my attempt at explaining what I think I understand: I don't think I made my arguments from the point of view that "I don't understand". If I did, you would have to point out specific examples. I made my arguments from facts to the best of my knowledge as a high level programmer and someone 100% fluent in the English language. However, I admit I can have misunderstandings. I'm here to both help and learn. > First off, terminology. I am only including relevant terms, not all > possible variants of every term: > * User interface (UI) > The part of a program that gets input and sends output. > > * console/text terminal > A character input/output device. It sends character input and receives > character output. It may interpret certain character sequences as > special commands. A historic (and important. we will come to this later) > example is the VT-100. All interaction with console apps happens via a > console (real or emulated). > > * Graphical terminal (not a common name) > The screen/mouse/keyboard/joystick/touchpad/touchscreen type devices we > are all used to today. > I was not suggesting an exhaustive definition of every possible term. I think the above goes overboard. For example, we do not need to define UI. I was pointing out that "regular windows program" is vague and misleading, I will not repeat the arguments here, and suggesting more specific / meaningful technical terms. > * Program > There are 3 types of programs, categorized by their UI and terminal use. > 1) A "regular" app. Has a stream-based UI. This is what you get when you > compile the standard "Hello, world!" C program. It has 3 abstract I/O > (character-)streams (stdin, stdout, stderr) allocated to it by the OS > upon starting. These streams are usually emulated/mapped by the OS over > the console's character stream, and may be buffered (depending on the > implementation) by the OS and/or the terminal and/or the library. The > streams may be redirected, such as by pipes or redirecting to a file. > Often the input stream is buffered and only sent to the app at a newline > or EOF, so the app has no control over the text entry phase. To correct > input you would typically have to erase (backspace) as needed and > re-enter input. Examples are ls, mv and pacman. > 2) A GUI app. This type gets no I/O streams allocated by default (it can > open streams using OS APIs if needed) and it's I/O is not character > based (graphic output, usually to a window, and multiple types of input, > such as pointer and keyboard). It uses a graphical terminal rather than > a text terminal. Examples are firefox, office or media player. > 3) A console based non-stream app. These types of programs use a > text-based console, but rely on directly communicating with the console > rather than via abstract streams. This of course means that they are > dependent on each console's particular capabilities and supported > features. 2 classic subtypes of this are the line editing type and the > TUI type. The former mostly uses it's direct console connection to > manage it's own buffering of input/output and to move the cursor around. > This can be used for various REPL apps, as well as things like gdb, > sqlite and many others. Often done with readline, linenoise or similar > library. The TUI type usually use a *curses library, and they rely much > more heavily on console-specific things, such as size, colors, special > keys, etc. Examples are vim, mc, etc. The above explanations are excellent. However, I don't think we need to go into detail explaining streams. Again, I think the above goes overboard. That information (GUI, streams) is explained elsewhere. We just need to clearly spell out the specific technologies (eg, GUI, streams, ncurses), instead of using vague terms (eg, regular windows program, or "just know"), or undefined obscure jargon like REPL. Instead of "regular app" (vague), I would suggest "command-line app" or even "CLI app" (command-line interface). Instead of "A console based non-stream app" (wordy), I would suggest "TUI app" (text user interface). For every concept, having a brief, snappy form would be helpful. Also, to my understanding, these categories need to differentiated between those intended for running under MSYS2 and those running under win32 console (command prompt), since I believe they are compiled differently. > * console emulator/virtual terminal > This is a GUI app that emulates the console input by translating input > from the GUI input method (keyboard or other) into console character > stream, and the console output to a graphical output in a window. It > will generate/parse the special commands/escape sequences as needed. > Many (most?) terminal apps simulate some form of the VT-100 terminal. A > notable exception is the Win32 console, that dos not simulate the VT-100 > escape sequences. I don't know if it even emulates any actual terminal, > or just does its own. Examples are xterm, gterm, Win32 console, mintty. > > * shell > This is a console app (usually type #3 line editing, but can be type #1, > or any type of #3 too). It parses its input to figure out what other app > you want to run, and runs it via the OS. Examples are bash, zsh or > Windows cmd. > > For the rest of this text, console, terminal and console/terminal > emulator are interchangeable. > > Now for the explanation of what is going on. > GUI apps are tied to an api, which usually ties them to an OS, unless > using an abstraction level for the api (Qt, wxWidgets, wine, etc.) > "regular" apps usually work just fine in any console, since they work > with abstract streams, which are basically supplied by both Windows and > Posix OSs with any console. > The problems start with type #3 apps. The more they rely on some special > console capabilities, specifically VT-100, the more likely they are to > break in Win32 console, and vice-verse. > winpty attempts to run the app passed to it in a hidden Win32 console > and translate the input/output from mintty (VT-100) to Win32 command and > back. Again "regular apps" is way too vague. As I explained in previous posts, I tested winpty with the pdcurses app that runs perfectly under windows, and runs perfectly under the bash.exe / window 7 "command prompt" combination. The pdcurses app DOES NOT run correctly under winpty / mintty combination. Arrow keys and other cursor keys do not work. So I think your wording "attempts" is correct, that winpty is lacking. I say "winpty program.exe" from within mintty. If there is some option I might need to be using to make winpty work better, I'd like to hear. "man winpty" and "winpty --help" fail. > > > This is my understanding. Please someone who understands this better > correct me as needed. I think your understanding is fine and your text is helpful. As mentioned before, a lot of the documentation might be derived from postings / discussions. > > Baruch > > > -- > ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 > > > > _______________________________________________ > Msys2-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/msys2-users > ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Msys2-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/msys2-users
