I've been trying to use it seriously for a bit....and while a lot is improved... so many of the features are half baked and awkward to use. It's definitely no tmux. It could be a lot better, but a lot of improvements are on the back burner and unlikely to be implemented for a long time. I tend to just use multiple old (but recently enhanced) terminal windows
Each to their own and all but I've always found it weird that some tmux users would spend hours setting up their keyboard driven interfaces (the terminal) and then prefer to use the mouse to switch between different applications running on it. Particularly when tmux has such a great support for keyboard hotkeys. I'm not out to criticise anyone's preferred workflow but it is a pattern that has always taken me a little by surprise.
For things like altering split-pane layouts, mouse remains king for both quickly & precisely adjusting width and height - at the same time, no less. Quickly moving focus to 1 random pane out of 6+ is also a single input, whereas with keys it can be up to ~(total number of panes - 1).
It's also a single config option to enable all mouse functionality, whereas setting up keybindings do just the resizing takes several lines.
> For things like altering split-pane layouts, mouse remains king for both quickly & precisely adjusting width and height - at the same time, no less. Quickly moving focus to 1 random pane out of 6+ is also a single input, whereas with keys it can be up to ~(total number of panes - 1).
You're not taking into account moving your hands from the keyboard and to the mouse, shacking it to find which where and on which screen your mouse cursor is located, and then putting your hands back on the keyboard after the resize.
However what we're really arguing about is negligible micro-optimisations anyway so it's a little silly to say one is faster or slower than another. :)
> It's also a single config option to enable all mouse functionality, whereas setting up keybindings do just the resizing takes several lines.
Keybindings for selecting and resizing panes are already defined in tmux's defaults. You don't need to configure nor enable it. However it is something you'd need to look up, commit to memory, then muscle memory after. Which I guess creates enough of an hurdle that many people haven't bothered to jump.
Why is she using PowerShell Core (v6) instead of PowerShell 7? This kind of shows that Windows Terminal developers are not that excited about PowerShell.
What's the relationship between PowerShell and Windows Terminal anyways? Which are you supposed to use for what? Are you supposed to run one within the other?
> What's the relationship between PowerShell and Windows Terminal anyways? Which are you supposed to use for what? Are you supposed to run one within the other?
Seems quite clear to me. Powershell is a shell, while Windows Terminal is a console. Windows Terminal can run any shell, such as Bash, Powershell 5, Powershell 6, cmd.exe, git shell, azure shell, etc.
Instead of each shell having its own console implementation, you have one, Windows Terminal.
Console's can be hardware (physical switches et al) as well as web based (AWS Console). "console" is also often used interchangeably with different layers of the stack such as the device you directly interface with (terminal emulator, physical console, etc), the transmission medium (eg RS232, sshd, etc), nor any of the console software stack (pseudo-TTYs et al). Console is a generic term for the management concept whereas "terminal emulator" is a specific term for a software application used to launch a command line.
I agree but it is what it is. The world is full of terminology that are steeped in legacy and sometimes don't even mean what the words literally describe. Why is a save icon a blue and grey box? What discs are those DJs spinning on their MBPs? Why do people hoover with their Dysons and Google in Bing? Why is fibre internet called "broadband" when fibre optics operate on a narrowband? Human languages are a clusterfuck at times.
The word has. The specific meaning has not. That's a thing that Microsoft invented, after all. (Microsoft was even in on the inventions of its several clear precursors, for which the name "console" hadn't yet been ascribed, such as the VIO/KBD/MOU subsystems in OS/2 1.x.) Windows Terminal most definitiely uses consoles, with the aforementioned meaning.
Microsoft didn't invent consoles. They have also been around longer than Microsoft have existed. The distinction you're making here is pretty tenuous and irrelevant to the original question being asked since we're talking about the terminal GUI not the console guts; and the fact that Microsoft even call this product "Windows Terminal" should make this an open and shut case.
Microsoft did invent this particular I/O abstraction, named a console. And it's only irrelevant if you disagreeing with "Windows Terminal is a console" is irrelevant. Were you irrelevant? (-:
Windows Terminal is built on top of the console I/O mechanism. It talks to consoles, as do the 1990s and later Win32 console applications that one can run displayed within Windows Terminal. Arguing with someone who says that "Windows Terminal is a console", as you did, based upon the product name is fairly flawed. The name for this I/O abstraction, invented by Microsoft for Windows NT and evolved from earlier operating systems, is a console.
If you want open and shut, by the way, one of the programs that is the innards of Windows Terminal is named OpenConsole.exe . It provides an enhanced implementation of the console I/O server, formerly conhost, and before that formerly CSRSS.
Just because Microsoft used a particular IO abstraction in conhost and called it a “console” it doesn’t mean they’ve magically got full rights to that term and nor does it mean that established, industry recognised terms for that same thing suddenly don’t apply. I could release a book tomorrow and call it a “hippopotamus” but that doesn’t mean it’s not still a book.
You get this all the time in IT, Chef calling their modules “recipes”, homebrew having “casks”, rust with its “crates”, etc. But that doesn’t mean they’re literally casks et al and no other established jargon henceforth applies. That’s just not how it works.
However this is all moot because even Microsoft don’t refer to Windows Terminal as a console[0][1] and more does anyone else[2] apart from you it seems.
I get that you’re trying to use precise terminology but what you’re actually doing is over analysing things by making distinctions out of things that aren’t relevant.
Wow. I downloaded and launched this, and immediately wanted to change the font size. Took me a good minute to find the settings button (cmd and Powershell both have a right click menu on the title bar, this one does not), and clicking on it opens a JSON config file with Visual Studio. Guess it's far from <s>ready for everyday use</s> release quality at the moment.
Disclaimer: I'm primarily a Mac user developing on macOS and Linux. Swears by iTerm 2.
I mean, quite a few apps aimed at developers do this. Sublime Text for example. I can't imagine many people who aren't comfortable editing a text file would be using a terminal.
The configuration file opens in whatever app is associated with the format.
If you associated JSON files with VS then that's specific to your personal setup and unrelated to the Terminal app.
You also don't need to learn JSON schema and - I'm sorry to say this - but if editing a well-documented text format is too much of a hurdle to you, then maybe you're simply not the target demographic for the app.
The tons of people who blindly use copy-pasta wouldn't even need to use the Terminal app (a tool explicitly aimed at power users and devs), so that's a non-argument to start with.
Thanks for labeling me a noob while I have been editing text configs for a decade and a half. Again, passable != good, and there’s hardly any defense for a GUI application putting all common settings in a text configuration, especially when you need to configure colors, fonts, etc.
I’m pretty sure the terminal app was advertised as the next generation console experience for Windows, which means it is going to replace cmd, and will be used by non-power users.
Re binding: that’s just the default when VS is installed. Also, whether it’s Visual Studio is irrelevant, what’s relevant is it definitely isn’t Windows Terminal.
Edit: By replacing cmd I probably meant replacing conhost or something. Not completely sure about Windows separation of shells and terminal emulators but the idea should be clear.
People who use a terminal know how to edit a json file. That approach has good tradition by now with Sublime etc, see the poster above. And I'm pretty sure VS doesn't auto-associate itself with json files. They handled this in the best way possible imo.
That's up to opinion. I just wanted to join in to voice another opinion since some people in MS have recently been on a "even a single opinion is enough to act" policy (see VS Santa hat debacle), which I'm trying to prevent.
> I’m pretty sure the terminal app was advertised as the next generation console experience for Windows, which means it is going to replace cmd, and will be used by non-power users.
I'd love to hear a legit day-to-day use case, though. I'm honestly very curious to hear about that since even as a developer, I pretty much never use the command line (outside of WSL, which I don't consider a typical use-case either).
I didn't say I never use a shell - I even explicitly excluded WSL.
When developing software in Windows, however, there's simply no need.
> How do you compile
I press F6 in my IDE.
> install dependencies
I click "Add nu-get package"
> etc. [I assume version control operations and the like]
Again, I simply use the built-in tools of my IDE of choice which are usually bound to hotkeys.
This is hard to fathom, especially for modern web development, but I don't do web development and the embedded systems I work with don't have a shell while the GUI programs have, well, graphical interfaces :)
> When developing software in Windows, however, there's simply no need.
This tells more about your skils then anything else. If there is NO NEED for that in your world, there is defintelly a NEED for you to dive into it - something you don't know you can't use or find a need for it.
I use the shell everyday for git, code search, running my code, SSH. I think on windows it's more common to use an IDE with a GUI for some of these things, but the CLI is generally more powerful.
I was rather curious about strictly non-power-user use cases. Someone who develops software and uses distributed version control systems isn't exactly the average user.
I work outside of software (or any technology really), so I deal with around 30 people who are the opposite of power users, all using Windows (with one on a Mac laptop). Not a single one of them would even know what a terminal is, and I include powershell and the standard command line in that. The only thing that runs on their machines via Windows cmd are scripts I install so I can use their machines if I have to get something done on it.
> and there’s hardly any defense for a GUI application putting all common settings in a text configuration, especially when you need to configure colors, fonts, etc.
It's a good place for them to be stored; it's not a great UI, but that is a thing that can be built over any storage and there is a reason it's v0.10 and not v1.0.
> I’m pretty sure the terminal app was advertised as the next generation console experience for Windows, which means it is going to replace cmd
ConHost. Cmd is a command interpreter that runs in a console, not a console itself.
> and will be used by non-power users.
Eventually, sure. It's very much a power-user-focussed preview today, though.
For what it's worth, I agree with you. JSON is meant to be machine readable rather than human writeable and while I don't mind reading through JSON files, I really don't enjoy editing them because it's easy to break (eg including a trailing comma on the last entry in a map or array).
The lack of comments in JSON is an often raised point and it's really useful being able to add comments in a "living" config file.
The other issue I have with many JSON config files is they don't always contain all the options, so you end up having to search around for what the right directive is to add to a particular config file (this is my biggest gripe with hacking VS Code config files). This is less of an issue with other formats because you can often comment out lesser used directives.
I think the reason JSON is popular for config files is because it's easy to implement rather than easy to maintain and I see JSON as a regression from the TOML / INI etc formats that used to be commonplace beforehand.
I also agree with your frustrations with the replies about "people who know how to use a terminal know how to use JSON"; sure they do but that doesn't mean it is appropriate usage of JSON. I could write a config file using golfed Bash and say "but you should know how to read and write Bash" but people would understandably dismiss that saying it's still not user friendly and I don't see your point here any different.
It was the same with VS Code.
Probably they won't start to transition to a more GUI oriented options until release.
Even then it'll probably be an incremental affair.
I personally find the JSON configuration paradigm to be immensely usable, at least when it's done in a schema/UI-assisted way (which is how vscode did it). I'm glad Microsoft is picking it up in their other software and I wish more software did it.
Also, for text box configs there’s usually a XML/JSON behind the scene anyway. It’s not like I can’t grep my iTerm config even though I configure it from the GUI.
Admittedly, the place where those settings are (and how they can be changed) is not terribly intuitive, either. It's just that it has been that way since at least Windows 3, so you (and many others) are probably used to it by now, while others don't even know this exists. I mean, how many people actually look into the system menu of an application?
It's meant to be used with WMs that can handle tabs (i3, sway, xmonad, ...)
As a terminal, it is blazingly fast and scale well with hdpi screens, without all the feature creep, in short, it suckless.
Then it's not meant for you then. Products have use cases that are not necessarily your use cases. With tmux, alacritty is great and doesn't need tabs.
Do you not use italics or strikethrough, then? Or scrolling regions? (Full-screen TUI programs rely upon setting scrolling regions to significantly speed up pane scrolls, so don't start by saying that you never use them.)
You are not the first person to go overboard calling it the best terminal ever. It clearly is not, yet. The developers themselves acknowledge that there's a way to go, yet, and maintain to-do lists of the many things that it as yet lacks. It does make me wonder, when it has simple deficiencies compared to the likes of XTerm, how seriously the people who claim "best terminal ever" have actually exercised any of these programs.
It opens the JSON file with your default JSON editor (same behavior VSCode had at its beginning, the settings UI came later). They're also going to develop a settings UI for Terminal but it will came later.
Also, since you're a Mac guy you'd be happy to know you can press ctrl + comma to open the settings
I agree! I primarily work on a Mac and love iTerm 2. I occasionally use a Windows computer and saw everyone raving about Windows Terminal a few weeks ago and decided to give it a go. It was quite a frustrating experience to try to configure anything. I eventually decided not to bother.
Finally a great terminal (although still bare bones) for Windows! Just 20 years late... we wanted that back in 2000. Instead if we had to use Windows, we got CMD.EXE that could easily resize vertically and not horizontally.
Bah. Terminal emulators are ancient hacks that should have died out long ago. Microsoft is just doing this to accommodate the Linux ecosystem that still thinks a teletype is a good idea.
Actually, the Microsoft people are doing this to satisfy a request from Windows software developers and users that was so prevalent that even I had a Frequently Given Answer about it back in 2000.
Feb 13: The v0.9 release of the Windows Terminal has arrived! This is the last version of the Terminal that will include new features before the v1 release.
Mar 17: Welcome to the v0.10 release of the Windows Terminal!
The plan is no new _features_ until 1.0. There was a good backlog of _bug_ fixes that were made since 0.9, so it made sense to push out an update with those, while continuing to work towards the eventual 1.0 release.
The die-hard fans here will kill you if you're anything less than ecstatic about the astronomical distance MS is ahead of its time with this. Being only about 40 years late with a pre-1.0 version is extremely progressive for µsoft.
Tried Terminal Preview and Hyper and Alacritty to get a decent working terminal, finally ended up using SSH and PuTTY that actually looks okay and works okay. Still has problems with some unicode characters. But PuTTY is mature and had support for mouse since when? 10, 15 years 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.
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.
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).
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.
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?
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.
VT100-compatible means exactly that - sending a set of control sequences to a VT100-compatible terminal app yields the exact same result as sending them to a physical device and vice versa.
The fact that some emulators offer additional features like ANSI-control sequences (e.g. for colour) doesn't change that. Same way a VGA card is still EGA compatible, etc.
> A console is a well-defined I/O abstraction in Win32, and has been for about 30 years.
In the Win32 API yes - but the Win32 API is not a user program now, it it?
Feel free to disagree, I'm perfectly fine with that.
Oh, and also feel free to tell Google and AWS to rename their control panels from API console https://console.developers.google.com and management console https://aws.amazon.com/console/ since both obviously abuse the oh so well-defined term...
They are using a different meaning. The particular meaning of the word console here most definitely is a well-defined I/O abstraction, and all of your argument about how console might mean something else and therefore there's no well-defined notion of a console in Windows is going completely overboard.
And it's sad that, despite the XTerm FAQ, you don't see the irony of waving around "VT100 compatible" as something supposedly well-defined, when the vt10x terminal types and the misapplied and sometimes downright erroneous notion of compatibility with various VT models has been the bane of users down the years. Here's another FAQ document.
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.
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.
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).
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.
In particular, "some" unicode characters. For example the "ghost" emoji works, but some (not all) of the powerline characters don't work. And I am using a font that is compatible with all these characters in other places (macOS).
Can't really put it to good use unless they release WSL 2 to Windows 10 1909 stable. Opting into the Windows Inside Program requires that you enable full diagnostic data being sent to Microsoft.
> Can't really put it to good use unless they release WSL 2 to Windows 10 1909 stable. Opting into the Windows Inside Program requires that you enable full diagnostic data being sent to Microsoft.
I use WT and native SSH (windows 10 now has openssh compiled for it and I think it's in default install these days) to connect to Linux boxes instead of say Putty.
Perhaps Ctrl+Shift+V, which is also used in a lot of Unix terminals since Ctrl+V usually would insert some control character that no one needs, but the hotkey cannot take that away.
Using the Control key for GUI shortcuts in a terminal, where control codes are part of the interface has always been an extremely dumb idea, just like backslashes as directory separators in path names, but that's Microsoft for you.
Huh? I'm not aware of any shortcuts using the Ctrl key in the console host (which uses function keys) or the new terminal (where the post I commented on complained that Ctrl+V does not work).
Meanwhile my corporation just bought new HP ZBook 14 which don't have Insert key. Instead it has dumb phone keys and something with a monitor painted on, 3 useless buttons instead of proper keys. No sysrq, no pause/break either. And this modes is supposedly for "work", not for gaming or media (from marketing point of view).
It is so frustrating to press extra keys just to have ctrl+ins and shift+ins.
This is a centralized upgrade, so they won't change the contract just for me and we don't have a BYOD policy here. Anyway - external KB alleviates it mostly, I'm just ranting at a corporations making "Pro" or "Workstation" devices clearly downgraded for these same categories - professional workers. Macbooks without F keys, lenovo cutting keyboards from best in industry to "meh" and so on.
At workplace this is what I do, mostly for better key profile - I'm using MS Natural 4000 with a front bar. But when traveling or working from home I'm using it as-is, with a laptop KB.
I shouldn't have called it "their JSON". Systems that accept HCL usually accept JSON as well, but HCL is much more human friendly. See https://github.com/hashicorp/hcl
Add-AppPackage : Deployment failed with HRESULT: 0x80073CFD, A Prerequisite for an install could not be satisfied.
Windows cannot install package Microsoft.WindowsTerminal_0.10.761.0_x64__8wekyb3d8bbwe because this package is not
compatible with the device. The package requires OS version 10.0.18362.0 or higher on the Windows.Mobile device
family. The device is currently running OS version 10.0.17763.1098.
It's not this release, but like since forever. There's a note in the github readme:
> Note: Windows Terminal requires Windows 10 1903 (build 18362) or later
"The Long-Term Servicing Channel (LTSC) is designed for Windows 10 devices and use cases where the key requirement is that functionality and features don’t change over time."
It won't help you, because this is probably managed by your IT department, but LTSC releases are generally not recommended. Those are primarily meant for systems like ATMs or industrial devices.
They seriously need to add a tab rename feature. Right click and rename. I am using it for development (along WSL2) and have 4, 5 tabs opened most of the time - a server, webpack, some ssh stuff, another server, something else.
All tabs have the same generic title name. There is a github issue, but it does not look like they take this feature seriously:
Pretty much every shell has its own mechanism for updating the title - the parent comment just shared the `powershell` way of setting the title. I'm confident that if you search for "set title from <your shell here>", you'll find plenty of posts on how to do it.
I can, right now, launch 4 different "terminals" in windows:
> cmd -- gives me the old dos-like command line
> wsl -- linux bash shell, which distro.. ¯\_(ツ)_/¯
> ubuntu -- ubuntu distribution, "on-top" of wsl?
> powershell -- new microsoft command line
Now, there's a "windows terminal"??? I don't get it. Is it supposed to be a "terminal emulator" like putty or terminus that can use any of the above 4? Does it emulate a VT100? with mouse?
This is confusing, how do these 5 things fit together?
Read the fine manual. Windows Terminal is a terminal emulator to cmd, wsl, pwsh, etc; a series of shells and runtime environments. And a pretty fine one indeed.
cmd and powershell are "console programs". They launch conhost.exe which is the text window you are interacting with. Another "console program" for example is https://en.wikipedia.org/wiki/Far_Manager. Or you can write your own.
When Windows is asked to run console program, it spawns conhost.exe and the console program is putting the text inside conhost's window. That was architecture since Windows NT time.
In Windows 10 timeframe there was an attempt to modernize conhost.exe and minor changes were made but ultimately the new approach was chosen.
Windows Terminal is the result of that approach. It's essentially new conhost.exe (more complicated than that, but good enough for this one) and it provides the text window for all the console programs such as cmd, powershell, Far, ssh etc. to run
Now let's get to wsl/ubuntu.
WSL - windows subsystem for linux. It allows Windows to run unmodified linux binaries. for example you can run Ubuntu on it. Or RedHat. Or CentOS, or Kali or a few other Linux distributions. Main way linux programs interact with the world is usually a text window (terminal) so originally conhost.exe was used for that. Now you can use Windows Terminal for this.
Think of Windows Terminal and conhost as "window" for text programs.
WT can host all of the others if you create a profile for them. It's replacing the chrome/window border around all of the others, not contents thereof. It's similar to ConEmu.
Def going to give this a try today. With CLion now supporting WSL as a toolchain I've now found myself in a strangely productive environment where Windows + WSL is my primary environment and I barely notice the transition between the two -- apart from the sub-par terminal experience. Looking forward to this...
I rly love 0.9 version.
The only thing that annoys me is resizing. When you open a tab and then you increase the window size, the actual terminal size is not increases with it. At least on my computer :-)
So I always need to first make the terminal fullscreen and then open tabs.
Is there a way to resize a pane? Normally one of my panes is just to run a process (like a local server) where I don't need to see output from it and 2 or 3 lines would suffice
172 comments
[ 3.1 ms ] story [ 41.1 ms ] threadThis is awesome. :)
https://www.youtube.com/watch?v=j0PPcUUtHlw https://www.youtube.com/watch?v=oHhiMf_6exY
It's also a single config option to enable all mouse functionality, whereas setting up keybindings do just the resizing takes several lines.
You're not taking into account moving your hands from the keyboard and to the mouse, shacking it to find which where and on which screen your mouse cursor is located, and then putting your hands back on the keyboard after the resize.
However what we're really arguing about is negligible micro-optimisations anyway so it's a little silly to say one is faster or slower than another. :)
> It's also a single config option to enable all mouse functionality, whereas setting up keybindings do just the resizing takes several lines.
Keybindings for selecting and resizing panes are already defined in tmux's defaults. You don't need to configure nor enable it. However it is something you'd need to look up, commit to memory, then muscle memory after. Which I guess creates enough of an hurdle that many people haven't bothered to jump.
What's the relationship between PowerShell and Windows Terminal anyways? Which are you supposed to use for what? Are you supposed to run one within the other?
Seems quite clear to me. Powershell is a shell, while Windows Terminal is a console. Windows Terminal can run any shell, such as Bash, Powershell 5, Powershell 6, cmd.exe, git shell, azure shell, etc.
Instead of each shell having its own console implementation, you have one, Windows Terminal.
Terminal emulator :)
"Console" can have a multitude of different meanings.
The entire terminology is a mess :p
Windows Terminal is built on top of the console I/O mechanism. It talks to consoles, as do the 1990s and later Win32 console applications that one can run displayed within Windows Terminal. Arguing with someone who says that "Windows Terminal is a console", as you did, based upon the product name is fairly flawed. The name for this I/O abstraction, invented by Microsoft for Windows NT and evolved from earlier operating systems, is a console.
If you want open and shut, by the way, one of the programs that is the innards of Windows Terminal is named OpenConsole.exe . It provides an enhanced implementation of the console I/O server, formerly conhost, and before that formerly CSRSS.
You get this all the time in IT, Chef calling their modules “recipes”, homebrew having “casks”, rust with its “crates”, etc. But that doesn’t mean they’re literally casks et al and no other established jargon henceforth applies. That’s just not how it works.
However this is all moot because even Microsoft don’t refer to Windows Terminal as a console[0][1] and more does anyone else[2] apart from you it seems.
0: https://github.com/microsoft/terminal/blob/master/README.md
1: https://www.microsoft.com/en-us/p/windows-terminal-preview/
2: https://en.wikipedia.org/wiki/Windows_Terminal
I get that you’re trying to use precise terminology but what you’re actually doing is over analysing things by making distinctions out of things that aren’t relevant.
Well, previously you had the Windows Console Host. It's not that that window was in any way the responsibility of the console application.
https://github.com/PowerShell/PowerShell/releases/tag/v7.0.0
Disclaimer: I'm primarily a Mac user developing on macOS and Linux. Swears by iTerm 2.
Also, can do is one thing, likes to do (learning a JSON schema to change the font size) is something else.
Oh, and tons of people use a terminal under guidance when they need to accomplish something that’s otherwise difficult or impossible.
If you associated JSON files with VS then that's specific to your personal setup and unrelated to the Terminal app.
You also don't need to learn JSON schema and - I'm sorry to say this - but if editing a well-documented text format is too much of a hurdle to you, then maybe you're simply not the target demographic for the app.
The tons of people who blindly use copy-pasta wouldn't even need to use the Terminal app (a tool explicitly aimed at power users and devs), so that's a non-argument to start with.
I’m pretty sure the terminal app was advertised as the next generation console experience for Windows, which means it is going to replace cmd, and will be used by non-power users.
Re binding: that’s just the default when VS is installed. Also, whether it’s Visual Studio is irrelevant, what’s relevant is it definitely isn’t Windows Terminal.
Edit: By replacing cmd I probably meant replacing conhost or something. Not completely sure about Windows separation of shells and terminal emulators but the idea should be clear.
I'd love to hear a legit day-to-day use case, though. I'm honestly very curious to hear about that since even as a developer, I pretty much never use the command line (outside of WSL, which I don't consider a typical use-case either).
When developing software in Windows, however, there's simply no need.
> How do you compile
I press F6 in my IDE.
> install dependencies
I click "Add nu-get package"
> etc. [I assume version control operations and the like]
Again, I simply use the built-in tools of my IDE of choice which are usually bound to hotkeys.
This is hard to fathom, especially for modern web development, but I don't do web development and the embedded systems I work with don't have a shell while the GUI programs have, well, graphical interfaces :)
This tells more about your skils then anything else. If there is NO NEED for that in your world, there is defintelly a NEED for you to dive into it - something you don't know you can't use or find a need for it.
Especially on Windows.
Terminal is basic IT literacy. Or at least, it should be. And it can't be if you protect people from it like its some kind of baba yaga.
It's a good place for them to be stored; it's not a great UI, but that is a thing that can be built over any storage and there is a reason it's v0.10 and not v1.0.
> I’m pretty sure the terminal app was advertised as the next generation console experience for Windows, which means it is going to replace cmd
ConHost. Cmd is a command interpreter that runs in a console, not a console itself.
> and will be used by non-power users.
Eventually, sure. It's very much a power-user-focussed preview today, though.
The lack of comments in JSON is an often raised point and it's really useful being able to add comments in a "living" config file.
The other issue I have with many JSON config files is they don't always contain all the options, so you end up having to search around for what the right directive is to add to a particular config file (this is my biggest gripe with hacking VS Code config files). This is less of an issue with other formats because you can often comment out lesser used directives.
I think the reason JSON is popular for config files is because it's easy to implement rather than easy to maintain and I see JSON as a regression from the TOML / INI etc formats that used to be commonplace beforehand.
I also agree with your frustrations with the replies about "people who know how to use a terminal know how to use JSON"; sure they do but that doesn't mean it is appropriate usage of JSON. I could write a config file using golfed Bash and say "but you should know how to read and write Bash" but people would understandably dismiss that saying it's still not user friendly and I don't see your point here any different.
Annoyingly, they don't allow trailing commas, but I suppose it's easier to strip out comments before parsing than it is to customise the JSON parser.
That’s the main problem, not boxes.
Also, for text box configs there’s usually a XML/JSON behind the scene anyway. It’s not like I can’t grep my iTerm config even though I configure it from the GUI.
> Setting UI is just one the things I would expect to be unfinished or not done.
That’s what I thought too. Just stating the pain points, not blaming anyone for missing features in a preview release.
You lost me right there. I don't care how Alacritty wants the world to work. I care how I want things to work.
WT is meant to be used on Windows, where WMs aren't a thing.
You are not the first person to go overboard calling it the best terminal ever. It clearly is not, yet. The developers themselves acknowledge that there's a way to go, yet, and maintain to-do lists of the many things that it as yet lacks. It does make me wonder, when it has simple deficiencies compared to the likes of XTerm, how seriously the people who claim "best terminal ever" have actually exercised any of these programs.
> It's the best terminal I've used so far on windows and Linux.
Again its the best that I'VE used for MY use cases.
Also, since you're a Mac guy you'd be happy to know you can press ctrl + comma to open the settings
* https://github.com/microsoft/terminal/issues/1564
* https://github.com/microsoft/terminal/issues/4232
Note the discussion of JSONC in the latter.
Mar 17: Welcome to the v0.10 release of the Windows Terminal!
The terminal app is no replacement for PuTTY - they're orthogonal use cases. Terminal is a host app for text-based shells, no more, no less.
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.
A terminal is this thing: 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.
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?
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.
* https://invisible-island.net/xterm/xterm.faq.html#what_is_vt...
You've gone overboard. A console is a well-defined I/O abstraction in Win32, and has been for about 30 years.
The fact that some emulators offer additional features like ANSI-control sequences (e.g. for colour) doesn't change that. Same way a VGA card is still EGA compatible, etc.
> A console is a well-defined I/O abstraction in Win32, and has been for about 30 years.
In the Win32 API yes - but the Win32 API is not a user program now, it it?
Feel free to disagree, I'm perfectly fine with that. Oh, and also feel free to tell Google and AWS to rename their control panels from API console https://console.developers.google.com and management console https://aws.amazon.com/console/ since both obviously abuse the oh so well-defined term...
And it's sad that, despite the XTerm FAQ, you don't see the irony of waving around "VT100 compatible" as something supposedly well-defined, when the vt10x terminal types and the misapplied and sometimes downright erroneous notion of compatibility with various VT models has been the bane of users down the years. Here's another FAQ document.
* https://invisible-island.net/ncurses/ncurses.faq.html#no_pad...
* 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
(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.)
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.
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).
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.
I use WT and native SSH (windows 10 now has openssh compiled for it and I think it's in default install these days) to connect to Linux boxes instead of say Putty.
It is so frustrating to press extra keys just to have ctrl+ins and shift+ins.
I don't even know how to type "Insert" on my non full keyboard.
Add-AppPackage -path .\Microsoft.WindowsTerminal_0.10.761.0_8wekyb3d8bbwe.msixbundle
Add-AppPackage : Deployment failed with HRESULT: 0x80073CFD, A Prerequisite for an install could not be satisfied. Windows cannot install package Microsoft.WindowsTerminal_0.10.761.0_x64__8wekyb3d8bbwe because this package is not compatible with the device. The package requires OS version 10.0.18362.0 or higher on the Windows.Mobile device family. The device is currently running OS version 10.0.17763.1098.
"The Long-Term Servicing Channel (LTSC) is designed for Windows 10 devices and use cases where the key requirement is that functionality and features don’t change over time."
See: https://github.com/microsoft/terminal/issues/3843#issuecomme...
All tabs have the same generic title name. There is a github issue, but it does not look like they take this feature seriously:
https://github.com/microsoft/terminal/issues/1079
Edit: I am happy with it - they've been improving it constantly (for the last 4 months at least).
I can, right now, launch 4 different "terminals" in windows:
Now, there's a "windows terminal"??? I don't get it. Is it supposed to be a "terminal emulator" like putty or terminus that can use any of the above 4? Does it emulate a VT100? with mouse?This is confusing, how do these 5 things fit together?
Shell = interactive program.
Terminal = thing that displays a shell and sends input to it.
Now let's get to wsl/ubuntu. WSL - windows subsystem for linux. It allows Windows to run unmodified linux binaries. for example you can run Ubuntu on it. Or RedHat. Or CentOS, or Kali or a few other Linux distributions. Main way linux programs interact with the world is usually a text window (terminal) so originally conhost.exe was used for that. Now you can use Windows Terminal for this. Think of Windows Terminal and conhost as "window" for text programs.
It can do VT100, yes, and with a mouse.
So I always need to first make the terminal fullscreen and then open tabs.
Anyone having this as well?
https://cmder.net/
I tried terminal 0.9 and it crashed almost immediately (probably related to Japanese or something) so I don't yet have confidence in Windows Terminal
Cmder has a super precise and verbose settings UI. WT is config file for now.