3 ms·

Console = terminal in my lingo. PuTTY is a console/terminal, plus an SSH client. What definitions are you using by comparison?

qayxc 7y ago
In the software context PuTTY is a terminal program. It defines a virtual version of a hardware terminal and includes a defined character set, control sequences for displaying text, virtual screens (e.g. 80x40) and handling input (e.g. VT100). A console doesn't have these specific restrictions and definitions and is just a catch-all term for a (text-based) user interface for interacting with the OS, or a specific app. The Windows Terminal app is a host program for various consoles that in turn may implement terminal emulations and provide shells. It's not, however a terminal or console itself.
- mehrdadn 7y ago
  I... don't follow. Sounds like you're using "console" to mean TUI or CLI? That's not how I see anyone use it. Windows Terminal as far as I can see is just a program like xterm or GNOME Terminal. All of which are terminals or consoles, whichever you prefer to call them. They interact with TUI and CLI programs (another distinction we can shove aside here) like grep or nano or whatever.
  - qayxc 7y ago
    The term "console" isn't strictly defined. It's a catch-all term for CLIs an TUIs. Example usage outside your restricted view: computer games use consoles for interacting with the game engine (e.g. Half Life, Fallout 4, and countless others). A terminal is this thing: https://en.wikipedia.org/wiki/VT100#/media/File:DEC_VT100_terminal.jpg https://en.wikipedia.org/wiki/VT100#/media/File:DEC_VT100_te... And programs that implement terminals are virtual versions of the hardware. PuTTY and Hyper are SSH clients that pretend to be such terminal. xterm is also a terminal emulator, e.g. it emulates the hardware mentioned above. A console doesn't need to do this - in the context of software it's just a TUI/CLI window with no implied standards (screen size, input- and output sequences, etc.) behind it.
    - mehrdadn 7y ago
      Oh come on. You're linking me a picture of a physical terminal from 1978 to tell me why "console" is a vague term? First, the whole terminal vs. terminal emulator (I can tell how much you're bending over just to make this distinction) war needs to stop already. It's a pretty irrelevant distinction, like the whole STL vs. "C++ Standard Library" war people like to start online just to win a linguistic battle. Nobody talking about terminals needs to go through the trouble of saying "virtual" terminal every single damn time, when there's no relevant distinction, no reason to bring up physical terminals from 1978, and every reason to believe it's clear what they mean. Second, your usage is definitely nonstandard. "Console" definitely does not mean "CLI". You can say "console program", but that only clarifies that you're being vague about it and don't care about the details. But "console" as a single-word noun is generally used to mean the same thing as a "terminal", which is a program an actual user uses to interact with text-based UIs (TUIs). It definitely is not used to just mean "CLI". CLI just means the program (like 'cat' or even 'sh') exposes a command-line interface, which normally implies text. But it literally doesn't need to have anything to do with a console (or a terminal)... or the presence of a UI or even a user in the first place. It can be entirely designed around and called as a sub-command in a GUI program with some argv[] and stdin. Hence the term command-line interface. That's its interface to everything else... to contrast with, say, an API (for compiling against), or an ABI (for linking against). There's no console or terminal or user that needs to be involved for every CLI program, and in normal usage there isn't even a user involved for many (most?) invocations of CLI programs. Whereas I dare say a GUI or TUI without an actual (human) user is an aberration like having a steering wheel and buttons in a car, without a way for a driver to get in. It's physically possible, but a completely abnormal design and (ab)usage. And lastly, if you're claiming "console" isn't strictly defined, then surely you can't turn around and tell someone "You do realise the difference between a console and a terminal app?" like that?! You're literally saying there isn't a strict definition for it and also telling someone off for not following whatever definition you have in mind?
      - qayxc 7y ago
        Terminal is a defined term - full stop. You cannot interact with a terminal without adhering to a standard (like VT100). If you're still not convinced and try to tell me otherwise, then riddle me this please: what on Earth does the "VT100-compatible" in PuTTY mean according to you? A console has its origins in hardware as well, but is a very broad term even there - from game systems to keyboards, many things can be called a console. It's just used to describe hardware or software that enables user interaction with the connected system (be it hardware or software). This is strictly not the case with CLI programs, which don't have to be interactive at all. A terminal in computer science, however, has one single meaning and definition. You might not agree with it, fine, but disagreement doesn't change facts. A VT100-compatible SSH client just ins't the same as a `conhost.exe` replacement, no matter how much you want to argue history and commonly understood usage away.
  - leetcrew 7y ago
    it's a window that you can use cmd or powershell in.
  - deleted 7y ago
    [deleted]
JdeBP 7y ago
That is not the widely-used terminology of Microsoft Windows where a console is a specific I/O mechanism, different from a terminal. * http://jdebp.uk./FGA/tui-console-and-terminal-paradigms.html http://jdebp.uk./FGA/tui-console-and-terminal-paradigms.html That the word "console" may denote other things, including a part of a pipe organ, is irrelevant. When discussing Windows Terminal one is almost always talking about the Microsoft Windows I/O mechanism, that's been around since Windows NT 3. * https://docs.microsoft.com/en-gb/windows/console/consoles https://docs.microsoft.com/en-gb/windows/console/consoles (The parenthetical "terminal" is a relatively recent addition to the doco. Not a wise one in my view, because it confuses more than it clarifies.)
- mehrdadn 7y ago
  That definition isn't really used consistently by Microsoft as far as I've been able to tell (though I think it was in the past). If you go by that traditional Win32 definition then "CreatePseudoConsole" should've been called CreatePseudoTerminal or CreatePTY... after all, Windows already has real console functionality; it doesn't need a pseudo-console. It needs a pseudo-TTY. And if you go by that definition then IMHO the "Windows Terminal" would need to be called the "Windows Console"... But honestly usage of the word "console" was clearly not what the parent's argument was about, which makes it kind of irrelevant to the whole discussion... Edit: Regarding your edit linking to where even Microsoft says "A console (or terminal) ...": you can dismiss it all you want, but I rest my case.
  - JdeBP 7y ago
    It's only irrelevant if your immediately equating console and terminal in response, and then asking for a definition, was irrelevant. Were you irrelevant? (-: I dismiss it because there's a mountain of usage contradicting that johnny-come-lately parenthetical. It's a well-known distinction; documented by lots of people, including me for about two decades now (actually longer, 2000 is simply when I wrote the FGA). And if your case is based upon the Win32 API function naming scheme, your case is founded on sand. I should not need to explain why to any Win32 developer. (-: In reality, the thing that ConPTY gives one is not a pseudo-terminal, because the wrapped applications are talking to consoles as far as they are concerned. It's not the simple implementation that I would have chosen (https://news.ycombinator.com/item?id=17818942 https://news.ycombinator.com/item?id=17818942). It's a much more ambitious architecture, that aims to let terminal I/O applications talk to Win32 consoles as if they were old 1980s terminals, to let 1990s and later Win32 console applications have their I/O driven via systems that ship terminal I/O, and to let both the old 1980s terminal I/O applications and the 1990s and later console I/O applications almost seamlessly share a common screen and input buffer.

qayxc 7y ago

In the software context PuTTY is a terminal program. It defines a virtual version of a hardware terminal and includes a defined character set, control sequences for displaying text, virtual screens (e.g. 80x40) and handling input (e.g. VT100). A console doesn't have these specific restrictions and definitions and is just a catch-all term for a (text-based) user interface for interacting with the OS, or a specific app. The Windows Terminal app is a host program for various consoles that in turn may implement terminal emulations and provide shells. It's not, however a terminal or console itself.

mehrdadn 7y ago
I... don't follow. Sounds like you're using "console" to mean TUI or CLI? That's not how I see anyone use it. Windows Terminal as far as I can see is just a program like xterm or GNOME Terminal. All of which are terminals or consoles, whichever you prefer to call them. They interact with TUI and CLI programs (another distinction we can shove aside here) like grep or nano or whatever.
- qayxc 7y ago
  The term "console" isn't strictly defined. It's a catch-all term for CLIs an TUIs. Example usage outside your restricted view: computer games use consoles for interacting with the game engine (e.g. Half Life, Fallout 4, and countless others). A terminal is this thing: https://en.wikipedia.org/wiki/VT100#/media/File:DEC_VT100_terminal.jpg https://en.wikipedia.org/wiki/VT100#/media/File:DEC_VT100_te... And programs that implement terminals are virtual versions of the hardware. PuTTY and Hyper are SSH clients that pretend to be such terminal. xterm is also a terminal emulator, e.g. it emulates the hardware mentioned above. A console doesn't need to do this - in the context of software it's just a TUI/CLI window with no implied standards (screen size, input- and output sequences, etc.) behind it.
  - mehrdadn 7y ago
    Oh come on. You're linking me a picture of a physical terminal from 1978 to tell me why "console" is a vague term? First, the whole terminal vs. terminal emulator (I can tell how much you're bending over just to make this distinction) war needs to stop already. It's a pretty irrelevant distinction, like the whole STL vs. "C++ Standard Library" war people like to start online just to win a linguistic battle. Nobody talking about terminals needs to go through the trouble of saying "virtual" terminal every single damn time, when there's no relevant distinction, no reason to bring up physical terminals from 1978, and every reason to believe it's clear what they mean. Second, your usage is definitely nonstandard. "Console" definitely does not mean "CLI". You can say "console program", but that only clarifies that you're being vague about it and don't care about the details. But "console" as a single-word noun is generally used to mean the same thing as a "terminal", which is a program an actual user uses to interact with text-based UIs (TUIs). It definitely is not used to just mean "CLI". CLI just means the program (like 'cat' or even 'sh') exposes a command-line interface, which normally implies text. But it literally doesn't need to have anything to do with a console (or a terminal)... or the presence of a UI or even a user in the first place. It can be entirely designed around and called as a sub-command in a GUI program with some argv[] and stdin. Hence the term command-line interface. That's its interface to everything else... to contrast with, say, an API (for compiling against), or an ABI (for linking against). There's no console or terminal or user that needs to be involved for every CLI program, and in normal usage there isn't even a user involved for many (most?) invocations of CLI programs. Whereas I dare say a GUI or TUI without an actual (human) user is an aberration like having a steering wheel and buttons in a car, without a way for a driver to get in. It's physically possible, but a completely abnormal design and (ab)usage. And lastly, if you're claiming "console" isn't strictly defined, then surely you can't turn around and tell someone "You do realise the difference between a console and a terminal app?" like that?! You're literally saying there isn't a strict definition for it and also telling someone off for not following whatever definition you have in mind?
    - qayxc 7y ago
      Terminal is a defined term - full stop. You cannot interact with a terminal without adhering to a standard (like VT100). If you're still not convinced and try to tell me otherwise, then riddle me this please: what on Earth does the "VT100-compatible" in PuTTY mean according to you? A console has its origins in hardware as well, but is a very broad term even there - from game systems to keyboards, many things can be called a console. It's just used to describe hardware or software that enables user interaction with the connected system (be it hardware or software). This is strictly not the case with CLI programs, which don't have to be interactive at all. A terminal in computer science, however, has one single meaning and definition. You might not agree with it, fine, but disagreement doesn't change facts. A VT100-compatible SSH client just ins't the same as a `conhost.exe` replacement, no matter how much you want to argue history and commonly understood usage away.
- leetcrew 7y ago
  it's a window that you can use cmd or powershell in.
- deleted 7y ago
  [deleted]

JdeBP 7y ago

That is not the widely-used terminology of Microsoft Windows where a console is a specific I/O mechanism, different from a terminal. * http://jdebp.uk./FGA/tui-console-and-terminal-paradigms.html http://jdebp.uk./FGA/tui-console-and-terminal-paradigms.html That the word "console" may denote other things, including a part of a pipe organ, is irrelevant. When discussing Windows Terminal one is almost always talking about the Microsoft Windows I/O mechanism, that's been around since Windows NT 3. * https://docs.microsoft.com/en-gb/windows/console/consoles https://docs.microsoft.com/en-gb/windows/console/consoles (The parenthetical "terminal" is a relatively recent addition to the doco. Not a wise one in my view, because it confuses more than it clarifies.)

mehrdadn 7y ago
That definition isn't really used consistently by Microsoft as far as I've been able to tell (though I think it was in the past). If you go by that traditional Win32 definition then "CreatePseudoConsole" should've been called CreatePseudoTerminal or CreatePTY... after all, Windows already has real console functionality; it doesn't need a pseudo-console. It needs a pseudo-TTY. And if you go by that definition then IMHO the "Windows Terminal" would need to be called the "Windows Console"... But honestly usage of the word "console" was clearly not what the parent's argument was about, which makes it kind of irrelevant to the whole discussion... Edit: Regarding your edit linking to where even Microsoft says "A console (or terminal) ...": you can dismiss it all you want, but I rest my case.
- JdeBP 7y ago
  It's only irrelevant if your immediately equating console and terminal in response, and then asking for a definition, was irrelevant. Were you irrelevant? (-: I dismiss it because there's a mountain of usage contradicting that johnny-come-lately parenthetical. It's a well-known distinction; documented by lots of people, including me for about two decades now (actually longer, 2000 is simply when I wrote the FGA). And if your case is based upon the Win32 API function naming scheme, your case is founded on sand. I should not need to explain why to any Win32 developer. (-: In reality, the thing that ConPTY gives one is not a pseudo-terminal, because the wrapped applications are talking to consoles as far as they are concerned. It's not the simple implementation that I would have chosen (https://news.ycombinator.com/item?id=17818942 https://news.ycombinator.com/item?id=17818942). It's a much more ambitious architecture, that aims to let terminal I/O applications talk to Win32 consoles as if they were old 1980s terminals, to let 1990s and later Win32 console applications have their I/O driven via systems that ship terminal I/O, and to let both the old 1980s terminal I/O applications and the 1990s and later console I/O applications almost seamlessly share a common screen and input buffer.