Microsoft Is Making the Windows Command Line a Lot Better (arstechnica.com) 328
An anonymous reader quotes a report from Ars Technica: Over the last few years, Microsoft has been working to improve the Windows console. Console windows now maximize properly, for example. In the olden days, hitting maximize would make the window taller but not wider. Today, the action will fill the whole screen, just like any other window. Especially motivated by the Windows subsystem for Linux, the console in Windows 10 supports 16 million colors and VT escape sequences, enabling much richer console output than has traditionally been possible on Windows.
Microsoft is working to build a better console for Windows, one that we hope will open the door to the same flexibility and capabilities that Unix users have enjoyed for more than 40 years. The APIs seem to be in the latest Windows 10 Insider builds, though documentation is a little scarce for now. The command-line team is publishing a series of blog posts describing the history of the Windows command-line, and how the operating system's console works. The big reveal of the new API is coming soon, and with this, Windows should finally be able to have reliable, effective tabbed consoles, with emoji support, rich Unicode, and all the other things that the Windows console doesn't do... yet.
Microsoft is working to build a better console for Windows, one that we hope will open the door to the same flexibility and capabilities that Unix users have enjoyed for more than 40 years. The APIs seem to be in the latest Windows 10 Insider builds, though documentation is a little scarce for now. The command-line team is publishing a series of blog posts describing the history of the Windows command-line, and how the operating system's console works. The big reveal of the new API is coming soon, and with this, Windows should finally be able to have reliable, effective tabbed consoles, with emoji support, rich Unicode, and all the other things that the Windows console doesn't do... yet.
As usual, they are decades late (Score:2)
Still, it seems MS can eventually recognize what works. This will give all those GUI-only IT "experts" fits, of course.
Re: (Score:3)
Oh, well. As long as edlin still works.
Re: (Score:3)
There a few IT people that write IT software.
But honest question: anyone who uses windows at this time, are still using microsoft shells? like cmd and powershell?
The very first thing I install on windows machines is the nicely packaged git-shell stuff (NOT the github client). It will give me bash native on windows, almost better (or should I say, more practical) than cygwin.
Re: (Score:3)
RE > But honest question: anyone who uses windows at this time, are still using microsoft shells? like cmd and powershell?
yes, i live in powershell. its very robust and functional as well as being well supported by microsoft and the windows powershell community. i cannot speak to powershell CORE, which is the cross platform edition. it has a lot of limitations in what is available compared to v5 that I use because it is based on .NET core. the powershell window in win 7 is not great -- i have to still us
Re: (Score:2)
EDLIN is a 16 bit DOS program. Only 32 bit versions of Windows include the ability to run 16 bit DOS applications. As I recall with Windows 10, and possibly Windows 8, 16 bit capability must be separately enabled. It's not available at all on 64 bit versions of Windows.
Re: (Score:2)
Re:As usual, they are decades late (Score:5, Funny)
Next I would like to see Microsoft make CLI versions of all the traditional windows management tools, and
then for legacy GUI tools; Group Policy Editor, Active Directory Users and Computers, Domains And Trusts, Sites and Services.... make the traditional GUIs Read-Only solely for display and reporting
Re:As usual, they are decades late (Score:5, Informative)
You should really look into PowerShell, doubly so on Server.
Microsoft has something called the Common Engineering Criteria which lays out a set of requirements in order to ship something... as far back as 2011 (I think) there was a requirement that any administrative action you can do with the UI, there must be a cmdline option, with heavy emphasis on PowerShell. The exclusion to this is for pre-existing UI. Add/change a feature, cmdline equivalent is required, leave an older thing untouched in next release, it doesn't require touching.
Of course half of the exposed options were just WMI endpoints, which can be tweaked via PS even if no official cmdlets were created.
Source: Former MS employee.
Re:As usual, they are decades late (Score:5, Insightful)
powershell has some of the worse syntax I've ever seen in scripting. Way too much punctuation, object name lengths are too long, oh, and it's slow as fuck.
Re:As usual, they are decades late (Score:5, Insightful)
Amen, Brother. How on earth do they let such bad ideas percolate to the end user? I still haven't forgiven them for The Registry: want to change an operating system setting? Just remember this simple GUID: 229G-A17B-CC2E-82DD-E1AF-...
Powershell is not Bash (Score:5, Informative)
What more needs to be said. It is ... different.
Unix shell works on strings. Powershell works on objects. That is an important difference. Especially if the strings have funny characters in them.
As to speed, it is .net, so I presume compiles down to machine code.
Re:Powershell is not Bash (Score:4, Informative)
So think of it like an interpreted language that just happens to live in a Dotnet Ecosystem which allows it to instantiate and interact with DOTNET objects thus making it seem like a "DOTNET language". PowerShell has its own Extended Type System (ETS) that makes it more dynamic.. You can create objects on the fly with whatever properties you want, or take an existing dotnet object, and add stuff to it. PowerShell is a dynamic language. With dynamic scoping. It is a pipeline centric language, which passes rich objects through the pipeline (in contrast to binary/text pipelines in unix) PowerShell is a command (verb and noun) centric language in philosophy and implementation, and though it is a RICH Object language, i wouldn't say its object ORIENTATED. you can interact with objects, and create them, but the goal is to produce task based COMMANDS PowerShell lives in different environments. It is a line by line REPL Command line interpreter, but it is also a full scripting engine that can be embedded in other applications.
https://stackoverflow.com/ques... [stackoverflow.com]
Re: As usual, they are decades late (Score:2)
Maybe, but piping objects between scripts is fucking amazing.
Re:As usual, they are decades late (Score:4, Informative)
Next I would like to see Microsoft make CLI versions of all the traditional windows management tools, and then for legacy GUI tools
Your wish has been granted.... like.... nine years ago. Where've you been, dude and/or dudette? As a random example: Microsoft added Managed Service Accounts in 2008 R2, and you can see a "Managed Service Accounts" folder in AD Users and Computers, but you cannot create or edit them there. You -must- do it through Powershell using New-ADServiceAccount. Here's a blog post from 2009 [microsoft.com] on the subject.
Pretty much the only parts of Windows you can't configure through the command prompt, are some of the GUI elements. For example, there is no way to change what is pinned to the taskbar, nor can you programmatically set whether a tray icon will always be visible or not. Folks at Microsoft have said that this limitation is intended to protect the user from app installers that inject themselves all over the place. Setting crucial visual things like display resolution is also disallowed (except on Server Core, where there is no GUI to do this).
Re: (Score:2)
there are still some gui tools and powershell components that are not up to part, but really, powershell is where its at. anyone in the *nix world that is complaining about it, or still assuming the windows CLI is garbage, is really not very knowledgeable about what is available. I live in powershell for AD work, reporting events, moving files, monitoring services, manipulating data, comparing data....it can do almost anything these days. some people may not love the syntax, but i like that its verbose (usu
Re:As usual, they are decades late (Score:4, Insightful)
They're not decades late, they chose to be insular and keep things comparatively stupid. Now a few UI folks can fix it, having spent decades fixing the rest of their stuff.
Microsoft is about revenue, never make a mistake thinking there's an ounce of altruism in what Microsoft is, does, or plans.
If you want pointers to the body count, let me know. Or if the SCO-Linux-Kernel debacle wasn't enough, let's just say that they don't do UX for free...
Re: (Score:2)
Now a few UI folks can fix it, having spent decades fixing the rest of their stuff.
It's more than a UI problem, that's not a normal window. It's like some kind of bizarre DOS emulator, built for windows95 which requires (required) the screen to be a specific width. The source code is so ugly and messed up, no one dared to touch it. But now someone seems to have been working at it for a year or two, and they're cleaning up the code without breaking things (hopefully).
Re:As usual, they are decades late (Score:5, Insightful)
I'm a largely GUI-centric dev on Windows, but I think that's because Windows tends to work that way, and consequently has a lot of really nice GUI-based tools. For instance, there are nice GitHub desktop clients for Mac and Windows. But as for Linux? Nope - command-line only. So, when I work in Linux, I just sort of assume I have to keep various terminal windows open all the time, and that I'll probably be writing more scripts than when using Windows or Mac. It's just sort of the way things are done.
I'm comfortable working either way. However, I will say that I vastly prefer Bash to Powershell for CLI scripting. Bash is simple and fairly easy to pick up, if a bit on the clunky side. Powershell feels a bit over-engineered and overly-complex even when doing fairly simple things, and I've never bothered investing the time to really understand it all that deeply. So, I'm very happy about Linux tools, including Bash and various other CLI utilities, being ported to Windows. Because no matter how complete a GUI-based solution you have, there are almost always going to be times when you need to drop back to CLI tools if you're doing something outside of the GUI tool's expectations.
Re:As usual, they are decades late (Score:5, Insightful)
Re: (Score:2)
I don't know Powershell, but when I've encountered it I've been left with the impression that it's designed more as a programming language that you write while in an editor or IDE, with typing commands in from a command line prompt was a very late afterthought.
Re: (Score:2)
Re: (Score:2)
For instance, there are nice GitHub desktop clients for Mac and Windows. But as for Linux? Nope - command-line only.
You're talking out of your ass.
(lists of 3rd party clients)
A bit off-topic, but to clarify, I meant an official desktop client from GitHub the company, but didn't say that explicitly. You're correct, of course, that there are plenty of third-party clients that work across all OSes. I've been meaning to look at GitKracken at some point.
Re:As usual, they are decades late (Score:4, Insightful)
Still, it seems MS can eventually recognize what works. This will give all those GUI-only IT "experts" fits, of course.
As one of those people likely to be maligned as one of those "GUI-only IT 'experts'", I'll throw a few quick thoughts out there for your consideration.
First off, CLI doesn't always scale down. Making a hundred users in a domain environment? Sure, that needs to be scripted. Making just one? in most cases, quicker in a GUI environment.
Next, GUIs make things discoverable. using "/?" and man pages is a start, but the results of things aren't always readily obvious; GUIs can better reflect this. Discoverability is also helpful in scenarios where a task is done once every four months - recently enough to generally-remember it, long ago enough to forget the precise syntax. StackOverflow can help with that, but if lookup time is factored into the time entering the command, it's basically-impossible to make the time saving argument.
Finally, at least for myself personally, I don't administer the same exact set of systems all day, every day. I deal with everybody's systems. Some run Hyper-V, others VMWare, some have Sonicwalls, others have Barracudas or SOHO routers. Supporting end users means I need a functional understanding of their software, meaning I can somewhat-interact with a number of pieces of software specific to law firms, doctor's offices, restaurants, retail establishments, and others. GUIs (well-done ones, anyway) provide cues so I can generally figure things out upon first use if I know the underlying concepts. CLI syntax isn't as easy to pick up, especially in situations where the goal is to pick it up fast.
Sometimes, GUI is the right tool for the job, and the people that administer them are dealing with many, many different kinds of systems. It doesn't make them dumb (though there are PLENTY of dumb ones), any more than knowing how to use a CLI doesn't inherently make one smart.
Re:As usual, they are decades late (Score:4, Insightful)
There is nothing wrong with using a GUI when it is efficient for the task at hand. There is a lot wrong with calling yourself an "IT expert" when you cannot use or are severely limited on the command line.
Re:As usual, they are decades late (Score:5, Insightful)
The big caviat though is I'll bet a CLI guy has a better chance of success when GUI is the right tool than a GUI guy does if CLI is the right (or only) tool.
Learning CLI is well worth it.
Re: As usual, they are decades late (Score:2)
GUIs don't intrinsically make things more discoverable. Only GUIs specifically designed for discoverability.
If you think making edits in the registry or through Group Policy are discoverable, you're crazy. Even having different apps for different things (essentially all admin tools except MMC) tanks discoverability. Add to that a schemaless registry and scattered policy docs, and your GUI discoverability is going to essentially rely on Google to perform the discovery.
Re: As usual, they are decades late (Score:2)
OS X learned this lesson well. Simple GUIs, with advanced features only available from CLI. Windows tries to keep dumping more and more crap into the GUIs, until they are bloated and nigh unusable.
Re: (Score:2)
Late for whom? People who cared about the command line didn't use the command line, they used PowerShell. There was zero incentive to change anything, and lots of effort required to do it.
The commandline is a curious throwback shoehorned into Windows internals via a nonstandard process which is why it is able to be rendered even when the GUI breaks down in safe mode, which is why it is unable to be maximised, or one from TFA I never knew about, the process drawing the window crashing will cause the system t
Re: As usual, they are decades late (Score:2)
PowerShell has all the same problems as every other CLI Windows app.
Re: As usual, they are decades late (Score:4, Insightful)
Re: As usual, they are decades late (Score:4, Informative)
Re: (Score:3)
MaxOS X is a completely different OS from all the MacOSes that came before. CLI is not an afterthought for MacOS X. Next you'll be saying that pre-emptive multitasking is an afterthought in Windows because it was only introduced with WinNT.
Re: (Score:2)
Your speculations on what I wil say next is just silly.
Re: (Score:2)
MaxOS X is a completely different OS from all the MacOSes that came before. CLI is not an afterthought for MacOS X.
No one said it was. Maybe re-read the thread. Unless you think MacOS X predates NeXT...
Re: (Score:3)
Exactly. I use MacOS every days and spend half my life in iTerm. It is not even remotely an afterthought
Re: (Score:2)
Re: (Score:2)
No matter how you do your job, someone will eventually walk past and say that you're doing it wrong.
Re: (Score:2)
And sometimes they will be right. Your point?
Re: (Score:2)
They could be right, doesn't mean they're not annoying.
what (Score:5, Interesting)
Re: what (Score:5, Funny)
How the hell else do you expect a millenial to be able to figure it out?
Re:what (Score:5, Insightful)
Now Windows Console will support foreign languages.
With bigger and bigger Unicode character sets, every font will not only have emojis, and various human languages, it could also eventually have a set of font glyphs for every possible 8x8 cell grid. (That's only 2^64 characters extra in each font!) Then you could use these font characters to display text and graphics like it is 1980 again! That would make Windows Console great (again).
Re:what (Score:5, Insightful)
So it can do things that Slashdot still can't. The irony will probably be lost on the people acting smug over this being "late".
Re: (Score:2, Insightful)
Another aspie missing the point. Emoji support would come for free if Slashdot could even properly support UTF-8. You know a thing most websites have supported for years and years if not more than a decade.
Re:what (Score:4, Interesting)
Re: (Score:2)
I have a worse punishment. I think anyone using emojis on Windows Console should be forced to use the Windows OS.
Re:what (Score:5, Funny)
emoji is microsoft's systemd
Re: (Score:2)
can I fireup putty and login to an windows server? (Score:4, Interesting)
can I fireup putty and login to an windows server? or wait will I need to buy server 2019 to get this server side?
Re: (Score:2, Informative)
You've been able to do it through SSH for a year or so. You've been able to do it with PowerShell for quite a while now (a decade?).
Re: (Score:2)
Re: (Score:3)
You can fire up putty and login to any Windows machine providing it is in developer mode. Better* still you don't even need to fire up putty. Just use the built in ssh client in Windows. Get with the times.
*Actually not better. The built-in ssh client in Windows 10 is quite basic.
Re: can I fireup putty and login to an windows ser (Score:3)
I installed OpenSSH server on Windows over a decade ago. It was almost painless. Would it be nice to have it installed out of the box like OS X and most Linux distros? Sure. But that's hardly a significant difference between platforms.
Did they buy JPSoft? (Score:5, Interesting)
The best way to make CMD livable is to install Take Command. I've been using it since it was called 4DOS back in the pre-Windows days. It has always provided tab filename completion, history, etc (all those nice things in bash) and a much larger command set.
Re: (Score:3, Informative)
Re:Did they buy JPSoft? (Score:4, Insightful)
The best way to make CMD livable is to install Take Command. I've been using it since it was called 4DOS back in the pre-Windows days. It has always provided tab filename completion, history, etc (all those nice things in bash) and a much larger command set.
Why are you still using CMD in 2018? Why should anyone pay $100 per computer for the closed-source, proprietary Take Command when they could learn Powershell instead? Powershell has full Intellisense nowadays, access to the full .NET Framework library, comprehensive built-in documentation, and thousands of commands that can reach into every part of the system. Plus Powershell is an open-source Github project nowadays. Pair it with the open-source ConEmu for a wicked-good, fully configurable console environment.
Re:Did they buy JPSoft? (Score:4, Informative)
when they could learn Powershell instead? Powershell has full Intellisense nowadays, access to the full .NET Framework library, comprehensive built-in documentation, and thousands of commands that can reach into every part of the system.
Powershell redirect < doesn't work and redirect > can corrupt your files. Furthermore creating new CLI programs that integrate into the Powershell system is a pain. Powershell is great for administering Windows tools, but other than that, it's kind of crap.
Powershell is powerfull (Score:5, Insightful)
But way too verbose and complex... sorta like a java version of bash.
Re: (Score:2)
Re: (Score:2)
Re: Powershell is powerfull (Score:2)
The Verb-Noun naming convention for your functions is intolerable.
Re: (Score:2)
MS has too many ways to script OS-related stuff. They have the command window, power-shell and there are different-but-similar API's and languages they support (or half support). Choice can be good, but it can also confuse and dilute resources
Not only that, every time I have to write scripts in DOS cmd, I would rather stab myself with a fork.
So why is Microsoft doing this? (Score:4, Insightful)
Is it to keep up with the Linux's terminals, provide better displaying or Linux apps or establish bragging rights on who has the best console interface?
When I RFTA, they even note that while Unix/Linux is file based (which makes a "terminal" console more appropriate) Windows is object based with dialog based apps providing access to the system and utilities. I do quite a bit of development on Windows (7) and I really don't find that I need to access the system via the "MSDOS Prompt" console and, when I do, it's adequate for my needs.
So, while I would have liked a better console for MS-DOS 3.x and OS/2 1.x, I really don't see the need for revamping it for Windows 10 and beyond.
As for running Linux apps on Windows 10: I would rather suffer the minor inconvenience of turning 45 degrees to my Linux box rather than the major security risk of Windows 10.
Re: (Score:2)
1) Because users overwhelmingly want it (based on UserVoice)
2) Apple has stumbled / is stumbling and Microsoft wants to be there with interesting form factor computers and an OS that supports what those people prefer to make jumping ship easier.
Re: (Score:2)
Which users?
The users who already use powershell?
The users who install bash on Windows?
Certainly not the average user whose interaction with the terminal extends to that black screen that occasionally pops up when the IT administrator runs a script on their computer.
Maybe the BOFH wanted this so the script could then provide the poor user with a very BOFH emoji: U+1F595
On a more serious note this is somewhat at odds with the direction Microsoft has been taking of making Windows 10 more user friendly. Even t
Re:So why is Microsoft doing this? (Score:4, Informative)
They're doing it because MS is moving towards GUI less servers, current editions of Windows Server 2016 are "core" by standard, which means they don't install any GUI components.
Re: (Score:2)
I did not know that.
Thank you.
Translation: When we kill Linux as an OS.. (Score:4, Interesting)
When we take over and kill Linux as a stand-alone OS and make it available only under Windows, at least you'll have a command line window that won't make you cry -- even though your tears of loss over your silly little free 'open source' OS will still be sweet to us. Mark my words, Slashdotters, Miscreant-o-soft has had Linux in it's sights for a while now. Don't say you weren't warned when they lock it out of booting on your hardware.
wtf (Score:2, Informative)
WHAT YEAR IS IT?!?!
Re: (Score:2)
It's later than you think. And still too early for Microsoft.
Re: (Score:2)
Year of Linux on Desktop! (Seriously. [microsoft.com])
Re: (Score:2)
I still won't use Windows 10 (Score:5, Insightful)
Re: (Score:2)
Re: (Score:3)
Re: I still won't use Windows 10 (Score:2)
Don't mess it up, I use it daily (Score:2)
I dual boot and because of it my time is off in whatever OS I'm in. DATE and TIME are two commands I use all the time.
- Lost Linux Mint on a Windows update; didn't fix it for a bit, my time was always right.
Re: (Score:3)
You know you can fix that, right?
There is a registry key to tell Windows to use UTC, or use 'timedatectl set-local-rtc 1' to tell Linux to set the hwclock to local time.
No I didn't know it could be fixed, quick search on your reply looks like I can fix it.
Thank you.
X11 (Score:2)
I also know that various remote application services can do similar things (e.g. Citrix), but since we're already talking about a potential B-movie teleporter accident...
Re: (Score:2)
Re: (Score:2)
Uh, this is why you have Remote App stuff?
My experience has been that RDP is far more performant and reliable than X11 over the satellite links I have to deal with compared to X11 or VNC. Not as good as mosh, but we're talking GUI here.
Re: (Score:2)
When you think about it, it's not really surprising as to why.
Forwarding all interaction with the GUI, redraw events, inputs (a lot of events are generated as that mouse moves across that window), is a lot more data than a fixed-rate rasterized product sent with compression.
Paths, Filesystems, and Shells (Score:2)
Can we also get them to remove backslashes from paths, the /r from a newline, and add support for other filesystems and shells? That'd be swell.
Re: (Score:2)
cmd.exe has accepted either \ or / for path separators for years. You can even mix/match them within a command.
C:\Users\jeff>cd ../..\windows
C:\Windows>
Re: (Score:2)
Re: (Score:3)
Again? (Score:2)
Wasn't that supposed to be called Powershell? I guess I'm not the only one who didn't use it, huh?
Re: (Score:2)
No. Powershell is a shell. This is all about improving the console so the various shells (Powershell, cmd, etc...) can gain vastly improved output (amongst others) capabilities.
Emoji support? Yawn. (Score:2)
Emoji support? Call me when they include memoji support. That's where it's at!
"DOS Box?" (Score:2)
enough said (Score:3)
Re: (Score:2)
"Those who do not understand Henry Spencers quote are condemned to post it, irrelevantly." --thegarbz
Won't happen (Score:5, Interesting)
See, the UNIX paradigm has been something that Microsoft has never been able to swallow. Keep it simple. That's it. That's why all the UNIX commands we know and love have survived through the years, they are simple. They get the job done.
Stuff has been added, sure, but most of the original shell and common system commands have remained the same, decades on. Some 50 years of sameness and simplicity that Microsoft will never understand.
In all my dealings with Microsoft software, they seem to strive to make things as complicated and insane as possible. Even this new powershell, the commands are needlessly long, with long parameters names and very strict syntax. And not to be outdone, a whole new spam of technobabble error messages. Their APIs and programming languages are the same way, sure they are pretty powerful, but the complexity, nothing is simple. Simple isn't something Microsoft does. So they'll never be able to ever be 'unix' like.
Clink for older Windows (Score:2)
If you're still on Windows 7 or 8.1 like I am on most of my PCs, check out Clink [github.io] - an extension for the Windows command line that adds bash-style command line functionality to cmd.exe.
I was only just introduced to this by a colleague and can't believe I only just discovered it. Supports things like CTRL-V copy/paste which is pretty handy.
I'll finally be able to name folders with poop? (Score:2)
Re: (Score:2)
Re: (Score:2)
Assuming you want it to happen on a Hyper-V VM, do:
Debug-VM -Name "VM Name" -InjectNonMaskableInterrupt -ComputerName Hostname
Re: (Score:2)
Assuming you want it to happen on a Hyper-V VM, do:
Debug-VM -Name "VM Name" -InjectNonMaskableInterrupt -ComputerName Hostname
Also fun fact: the Debug-VM cmdlet takes input from pipeline.
So if you have a big Hyper-V environment you can do Get-VM | Debug-VM -InjectNonMaskableInterrupt on your host.
Big fun.
Re: (Score:2)
Re: (Score:2)