The day has finally come! Windows Terminal is now the default command line experience on Windows 11 22H2! This means that all command line applications will now automatically open in Windows Terminal. This blog post will go into how this setting is enabled, the journey of Windows Terminal along with its fan-favorite features, as well as give a huge thank you to our contributors who have helped throughout Terminal’s journey.
It’s still kind of surreal that after several decades, cmd.exe will now be relegated to the sidelines.
Wish they’d change the file separator to / as well, to get some sanity in the system.
iampivot,
It depends if they want to stay consistent with traditional DOS & windows convensions where \ is used by directories and / is a switch separator.
Changing it creates some new shell ambiguities.
“dir/w/o/s/p” could mean…
– execute “p.[exe|bat|cmd|lnk]” residing in the directory “dir/w/o/s”
– execute “dir” with one argument “/w/o/s/p”
– execute “dir” with multiple arguments “/w” “/o” “/s” “/p”
IIRC the unix shells I’ve used on windows (through cygwin and ming) were able to mix both \ and / in directory paths, however that would imply \ doesn’t have the same character escape semantics. Personally I don’t care about DOS syntax because I’ve been using unix shells for so long, but who knows, maybe other people still want to use \ for directories.
I’ve hated \ since day 1. Sadly, I can’t see Microsoft abandoning it.
The reason i dislike \ is that it is a three button press to print out on a swedish keyboard. “Ctrl”+”Alt”+”plus key”, it got somewhat better when they standardized the swedish keyboards to mandate a “AltGr” key so now it is a very awkward to do gesture for me with the right hand “AltGr”+”plus key” so i still tend to use the old way most of the time.
“Abandoning” maybe not, but the Win32 API accepts either path separator and treats them as equivalent. The issue, as Alfman points out, is individual tools whose parsing requirements interpret them differently before paths get to Windows. My shell (Yori) allows forward slashes where they are not ambiguous (eg. C:/Windows.) A lot of the ambiguities Alfman mentions are solved by requiring a space between command and arguments – the remaining one is specifying the root of the current drive as a file.
Note that there are other similar ambiguities that have existed for a while. Colon indicates a drive name but also is a named stream separator. So “a:b” refers to “file b on drive a” but “aa:b” refers to “named stream b on file aa.” Obviously you could have a file called “a”. So then we end up with goofy things like “.\a:b”.
You are “correct” in that using backslash as an escape (something that predates anything Microsoft) isn’t likely to happen, Microsoft now has a Terminal!! I’d like to welcome Microsoft to 1980’s. Progress.
RT-11, which was the inspiration for CP/M (which then largely inspired MS-DOS and compatibles) used / to define command switches. RT-11, however, had no concept of directories, with all files being in the root of a storage device.
Obviously, in creating CP/M, the idea of / being used for command switches was retained, which meant another separator was required for directories. Evidently, since / was used as a directory separator in UNIX, the next best thing which wouldn’t be ambiguous was \
So don’t blame Bill Gates, blame Gary Kildall.
They’d need a new shell, not a new terminal emulator. As others have commented it would be difficult to modify one of the existing shells for this behavior. This ( the ‘/’ as a directory separator) is half of the reason why I don’t use powershell unless I have to, The other part being the lengthy syntax. But you can absolutely use windows terminal with WSL powered distros like ubuntu or debian, then you can use / with aplomb.
I love Windows Terminal, and excluding working with and supporting some legacy Win32 apps I’ve pretty much abandoned the CMD prompt for PowerShell. Slowly over time I’m updating all my own scripts, I expect a lot of developers to do the same.
@iampivot, WSL already makes use of ‘/’, which is sort of the whole point of using Windows Terminal.
Note this change has nothing to do with cmd.exe. Cmd is the thing that parses text and outputs text. Terminal is the thing that generates bitmapped graphics from that text. Terminal includes a Cmd profile.
I’m not sure of the long term strategy, but I’m assuming like Powershell we’ll see compatibility layers added to Windows Terminal such that it becomes the ubiquitous interface to many and varied underlying command shells and utilities.
One interface to rule them all!
It already does this; it has profile support for cmd, powershell, WSL and is extensible to others, IOW you can have a single Terminal window where each tab targets a completely different profile/environment.
I’m still not upgrading to Windows 11, Satya.