Windows Terminal Preview v0.10 Release
devblogs.microsoft.com
devblogs.microsoft.com
So I always need to first make the terminal fullscreen and then open tabs.
Anyone having this as well?
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).
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...
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.
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.
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.
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.
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.
It is so frustrating to press extra keys just to have ctrl+ins and shift+ins.
"keybindings": [
{
"command": "copy",
"keys": [
"ctrl+c"
]
},
{
"command": "paste",
"keys": [
"ctrl+v"
]
}
]
I don't even know how to type "Insert" on my non full keyboard.
This is awesome. :)
https://www.youtube.com/watch?v=j0PPcUUtHlw https://www.youtube.com/watch?v=oHhiMf_6exY
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
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.
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