
Rumors of Cmd’s death have been greatly exaggerated - MikusR
https://blogs.msdn.microsoft.com/commandline/2017/01/04/rumors-of-cmds-death-have-been-greatly-exaggerated/
======
quotemstr
Windows really needs a public psuedoconsole API.

For the uninitiated: cmd.exe is the shell, like bash. conhost.exe is the
terminal emulator, like xterm. bash or cmd (the shell) talks to the terminal
via its standard input, output, and error file handles. Terminal handles are
like full-duplex pipes, but richer _: they transmit all the information needed
for interaction with the user. Each terminal handle has two ends:_ master* and
_slave_. The slave is the terminal to which cmd or bash talks; it basically
emulates a teletype. The master handle allows for reading both in-band and
out-of-band information from the slave terminal handle and supports special
APIs that allow anyone with access to the master handle to fully emulate a
terminal.

POSIX systems allow anyone to create master and slave terminal handles. When
you start xterm, xterm calls openpty, gets master and slave handles, starts
your shell with the slave handle, and uses the master terminal to get the
information needed to draw characters.

There's no equivalent for Windows. The only Windows program that can call the
Windows equivalent of openpty is conhost, which ships with the operating
system. It's not possible for a _different_ program to make a master-side
terminal handle. There are two workarounds, which both suck: 1) use pipes, not
console handles, and 2) make a hidden conhost.exe and scrape it. The former
causes programs to think they're being run non-interactively, with all sorts
of negative side effects (like excessive buffering). The latter loses screen
updates, is inefficient, and is generally awful.

Microsoft could easily make this situation much better by opening the protocol
that conhost uses to communicate with the kernel. If any program can create a
console handle, it's much easier to implement things like ssh daemons, Cygwin,
and terminal emulators that suck less than conhost.

...

* As an aside: when bash talks to xterm, it uses _in-band signaling_ (mostly: see termios): it sends control code sequences, which xterm understands as "move cursor to 3,3" and "set color to green". By contrast, when cmd communicates to conhost, it uses _out-of-band signaling_ : it uses special API functions to move the cursor and set the text color.

~~~
majkinetor
Conemu doesnt suck and it uses method 2. It has few quirks but nothing serious
and is almost on pair with usability as tmux and in some aspects even better.

~~~
_ix
I use conemu at work. It's not as awful as some alternatives. I would
recommend it, but I can't say that it's a good experience. Maybe I'm doing
something wrong here... do you run vim in conemu? For me, it's slow when
redrawing lines of text while paging and sometimes renders artifacts in the
pane, especially when I vertically split vim.

For a command line interface, I find it to be fairly unstable, too.

~~~
vishbar
I use vim in cmder occasionally. The only way I've been able to use it
properly is to disable conemu hooks before I execute it.

Basically, I've defined a function my profile to:

* Save the ConEmuHooks environment variable value * Set it to "Off" * Execute vim * Reset it to the previous value

I alias this command to "vim".

It's not pretty at all, and it caused me to use Sublime or VSCode most of the
time, but it worked for me.

More info here:
[http://conemu.github.io/en/ConEmuEnvironment.html](http://conemu.github.io/en/ConEmuEnvironment.html)

~~~
majkinetor
Why would you do that when gvim is available and is ways better experience
then vim ? For the sake of being shell purist ? On remote shell ?

------
MrRadiotron
> Typing “cmd” (or “PowerShell”) in File Explorer’s address bar will remain a
> quick way to launch the command shell at that location.

Where the hell is this stuff documented?!

~~~
eptgrant
This has just changed my life.

I thought right click -> Open Command Window Here was the only way. (Sometimes
need to hold shift? Maybe just in user directories)

~~~
emmanueloga_
On a related note, I recently discovered WoX [1] and I'm pretty happy with it.
I think it is an even more convenient launcher: Alt+Space from anywhere, type
cmd, ENTER.

With a couple plugins you can type things like "win <TAB>" to select from a
list of open windows, "g search-term" to google a term, etc.

1: [https://github.com/Wox-launcher/Wox](https://github.com/Wox-launcher/Wox)

~~~
NetStrikeForce
The plugins part I understand, but Alt+Space, type cmd, ENTER wouldn't be the
same as "windows key, type cmd, ENTER" that's been available for a few years
baked in the OS?

~~~
ptx
...or Win+R, "cmd", enter – which has been there for more than 20 years.

~~~
emmanueloga_
Because Win+R doesn't autocomplete the command, other than the history of
things you already run. WoX will pickup and do fuzzy completion on all
programs of the start menu, for instance.

------
majkinetor
Powershell should have been set as default years ago, particularly on core.

It escapes me how windows admin community still largely ignores Powershell
while clicking next in the loop.

Until MS makes Windows Powershell first, adoption will change very slowly as
we witnessed so far. Nano server will hopefully bring it faster.

Its a terrible injustice as posh is best shell in the existence IMO.

What I really want to see in future is exporting entire control pannel config
as posh script. This is the perfect time to digg into it given that control
panel is being transformed into 'settings'.

~~~
int_handler
Except Powershell isn't a real shell in the same way that cmd or any of the
POSIX shells are. It's a REPL for a language running on the .NET VM. I'm
neither a fan of the language nor having to wait several seconds due to the
latency of having to start the .NET VM when you start posh.

~~~
ygra
What _is_ a shell for you then? If the defining characteristic is that it's
not written in a managed language, well, okay, but I don't think many people
share that sentiment.

I have observed the several seconds startup time last with PowerShell v2 or so
and that was not the time needed for the CLR to start, but rather PowerShell
which was slow to start. v5.1 starts instantly here and the only slow thing
about it is my profile, which admittedly does a bunch of things that take time
(it's not yet at a point where it's annoying me so much that I edit it, and I
can start typing commands during that time anyway (considering that I often
spend more time thinking about what to write that's okay)).

~~~
flukus
> What is a shell for you then?

A way to execute programs. The parent is right, powershell is more like a REPL
to execute .net code. It's still no where near as good as a unix environment.

~~~
ygra
But as long as you only execute programs a script for cmd, bash, PowerShell
and a number of other shells looks pretty much the same. In PowerShell
executing a program is simply to state the program name (barring spaces in the
path for now). You don't have to do something like execute_program(name, args,
input_redirection, output_redirection, ...). Well, you _can_ , if you're so
inclined, but it's usually unnecessary. Any shell is "just a REPL for a
scripting language". Interactive use is one of the tenets of a shell,
otherwise it's more a batch processing system, I guess. And just like in other
shells the language is one geared towards running commands (cmdlets or
external), managing their execution and processing their output. That it works
better for general programming than many other shell languages (in my eyes) is
a nice bonus.

Heck, running programs is even easier than in most other shells since there's
a specific token that stops argument parsing completely which means you don't
have to care about quoting at all (an ever-present nightmare at times).

~~~
flukus
The difference is that windows/PowerShell don't provide the programs that make
a she'll useful.

~~~
ygra
Wow, then I've done a _lot_ of apparently-useless PowerShell work.

I beg to differ, by the way. Different is not the same as »not useful«. It's
not a traditional Unix shell and doesn't pretend or want to be. That doesn't
make it useless, just different.

~~~
loopykidney
I agree that powershell is far from useless, but it does feel like there are a
lot of cmdlets missing out of the box. It's real easy to end up in Get-
WmiObject land for everyday admin tasks.

~~~
ygra
But WMI is really, _really_ huge. I can understand that there is a bit
resistance to providing cmdlet wrappers around every single WMI class,
although I think on Windows Server there are a _lot_ more things exposed by
default (and I think even more in modules that are not loaded by default).

Also, since PowerShell can work with WMI objects natively it's already close
to what a cmdlet can provide.

------
frou_dh
I was happy to find out about Clink:
[https://mridgers.github.io/clink/](https://mridgers.github.io/clink/)

It's not a cmd.exe replacement/wrapper - it just hooks the program and beefs
it up with decent stuff like Unix style keybindings, history and completions.

------
intrasight
For C# developers, have a look at csi (C# Interpreter) as a potential cmd
replacement. I've been using it extensively for a couple weeks and like it
very much. Also, the same scripts can, with little modifications, be posted to
Azure Functions to run on the cloud.

~~~
rubber_duck
Last time I tried this there was no way to load nuget references. Very limited
usability if that's true.

I wasn't trying to use it as a shell replacement but like a REPL for
interactive development/prototyping. F# works better for this IIRC but I have
not used F# several years - need to brush up on it.

~~~
intrasight
When I work locally, I have a dummy VS project for grabbing assemblies from
Nuget. With Azure Fuctions, your function.json file can reference nuget
packages.

------
smithkl42
I use Powershell as my default command shell (via ConEmu). But its verbosity
makes it a pain to work with as your everyday shell. For instance, in cmd.exe
you can say:

dir /od

But in Powershell, you have to do:

dir | sort-object LastWriteTime

I totally get the Powershell verbosity when it comes to writing scripts. But
it can be a PITA when you're using it interactively.

~~~
latkin
First off, if you are using built-in `dir` alias, why not use the `sort`
alias? Note also that you get tab completion for `dir`, `sort`, and
`LastWriteTime`, so "verbosity" becomes decoupled from "speed of entering
commands", which is the real goal.

    
    
        dir | sort LastWriteTime
    

I think many in the "Powershell is too verbose for interactive use" camp have
simply been trained by cmd to have a very narrow view of what is appropriate
for interactive shell execution. Cmd's syntax and toolbox is so poor that only
the simplest of tasks are considered tractable for interactive scripting -
doing anything non-default is incredibly difficult (or impossible) without a
dedicated flag on some windows util (e.g. `/od`). Thus you come to a state
where the only commands anyone enters interactively in cmd are very short and
simple - not because the language is concise but because it's too painful to
attempt anything more.

Translating that narrow set of cmd-suitable tasks into Powershell, one finds
that indeed on average Powershell is a bit more verbose, and one says stuff
like "Powershell is more verbose than cmd".

What you're missing is that Powershell actually gives you a general, complete,
and uniform set of tools, which really are fairly concise given their power.
The space of tasks which are now suitable for interactive scripting is now
_vastly larger._

So before you say Powershell is "too verbose", I ask how concise batch/cmd is
for the following tasks:

    
    
        # assign earlier result to a variable (quite hilarious the gymnastics cmd makes you do simply to assign stdout to a damn variable)
        $x = dir | sort LastWriteTime
    
        # sort by the modified *date*, then by filename
        dir | sort {$_.LastWriteTime.Date},Name
    
        # get the sum of file sizes in the current dir, in MB
        (dir | measure Length -sum |% sum) / 1MB
    

Many would reply to this with something like "well if I need to do something
like that I'd be using C#/Python/VBS". That's my point! With powershell you
have a great interactive shell for super short stuff like file copies or `dir`
listings (not the case for C#/Python/VBS), but ALSO the ability to do powerful
general scripting with one-liners in the shell.

My "everyday shell" usage frequently covers scenarios similar to or more
complex than my examples above. I am quite happy to pay a minor verbosity tax
on the trivial commands so that I have the power to do the non-trivial stuff
without leaving the shell.

------
Insanity
When I started working on Windows again at the end of last year, the first
thing I did was pin PowerShell to the taskbar.

I have not used the plain CMD for a long time and would not go back to it.
Muscle memory makes me type "ls" in any directory I enter when looking around
for something, the fact that PowerShell has this is already a reason for me to
use it.

I'm not a heavy PS user though, and feel that it still compares poorly to
Linux or Mac's terminal for that matter.

~~~
alkonaut
The terminal itself is poor, but PS the language is so much more sane and
ergonomic than bash. Doing text-in-text-out where the sed/awk/split/sort
relies on _every_ program in the chain (perhaps a git log, or an ls or
whatever) to spit out its text in exactly the same way it always has just
feels like a terrible idea.

Example: count the number of files of each extension in the current direcory
and list the results alphabetically by extension (I honestly didn't pick this
as a way to show of PS strength and I realize that you can always pick a
benchmark that shows what you want - but I wanted something small and
understandable).

PS:

    
    
        ls | group Extension | sort Name | select Count, Name
    

bash:

    
    
        ls | awk -F . '{print $NF}' | sort | uniq -c | awk '{print $2,$1}'
        

These lines accomplish the same thing, with about the same amount of typing
required. You can argue that objects are brittle too, or that text is a
universal format whereas objects are not. But you can't tell me the bash line
looks better, or that for everyday tasks PS is always a verbose mess. Also:
just typing the bash line on my keyboard includes hitting Ctrl+Alt/AltGr
_eleven_ times!

~~~
cogs
I don't see we should have to learn a new language for this at all.

The set based paradigm of SQL lends itself very well to reporting and
processing files, and is known by 7 million people.

SELECT extension, count(*) FROM files GROUP BY extension ORDER BY extension;

We built a tool, free for personal use, that does SQL at the command line

[http://etia.co.uk](http://etia.co.uk)

~~~
alkonaut
Shells aren't file processing only - you process anything (dates, logs,
configs, environment, apps, ...).

Unless the underlying _model_ has all of that, I don't see how it competes
with bash/ps

It should be doable but requires more than a filesystem relational model

Select * from processes order by priority

I mean I see the benefit of using Sql, had I mastered it, for files, but I'd
be reluctant to sort and group reg keys or users or devices or processes or
env vars differently from _files_ in my shell language. You must have a
"relational model" for the file system, do you have a way to (or plan to)
generalize this to general structured data?

------
andrewclunn
> Cmd is one of the most frequently run executables on Windows with a similar
> number of daily launches as File Explorer, Edge and Internet Explorer!

Wait, they track that?

~~~
symlinkk
I would be interested to know why you are being downvoted.

~~~
ralish
Because it's well known by anyone interested in this area? There's been a
barrage of "Windows 10 Telemetry/Privacy" related stories since its release.
It's also publicly documented by Microsoft itself:
[https://technet.microsoft.com/en-
au/itpro/windows/manage/con...](https://technet.microsoft.com/en-
au/itpro/windows/manage/configure-windows-telemetry-in-your-
organization?f=255&MSPPError=-2147217396)

 _" Performance and reliability data, such as which programs are launched on a
device, how long they run, how quickly they respond to input, how many
problems are experienced with an app or device, and how quickly information is
sent or received over a network connection."_

------
sean_patel
From the Article:

> Notice the nuance here: The above paragraph states that “[PowerShell]
> replaces Command Prompt (aka, “cmd.exe”) in the WIN + X menu, in File
> Explorer”s File menu“. It does not say “[PowerShell] replaces Command
> Prompt“, period! The paragraph even goes on to show you how to quickly
> launch Cmd, and points out that you can revert this default setting to
> launch Cmd by default instead if you prefer.

and

> So, to be ultra-clear here: All that’s happening is that, in the [Win] + [X]
> (“Power User’s menu”), or File Explorer’s File menu, PowerShell is presented
> instead of Cmd. That’s all! Nothing is being removed, your scripts will
> continue to run just as they always have, the sky is not falling!

Looks their Release Notes writer did a poor job of explaining this, so all
hell broke loose and now they forced the "Commandline" Blog Team to write a
blog post screaming in CAPS and with Underlined words and Big Fonts (and even
more confusing language and punctuation), to tell everyone _-_ what they
really meant to say _-_ in their release notes.

~~~
ralish
Agree that the phrasing could have been a lot clearer, but really, Microsoft
removing cmd just doesn't pass even a basic sanity check. I remember seeing
the original news articles and just ignoring them as obviously rubbish. It's
pretty sad to see so many tech news sites & aggregators just pick-up and run
with stories like that which anyone at all knowledgeable about the subject
area would immediately know is hyperbole.

~~~
samplatt
They implemented bash into Windows 10, and their web-ish/app-ish "platform"
Silverlight does not work in their own browser in Windows 10 and isn't
intended to.

Microsoft have improved leaps and bounds in the last few years but saying that
a story is immediately hyperbole because "X-good-technical-reason" isn't
something I'm willing to commit to for any large corporation.

~~~
ralish
Sure, but the degree of usage of cmd makes Silverlight's usage look like a
hobby project. It's used _everywhere_ , including all over Microsoft's own
software. It'd easily be the single biggest backwards incompatible change ever
made by Microsoft and would affect software going back to the 1980s. The
engineering effort involved to migrate anything that is using cmd is mind
boggling, to the extent of being completely infeasible. It's a safe bet that
for as long as Windows is around, cmd is going to stay with it.

~~~
Twisell
And this is exactly because of this mentality that windows next move is to add
a Unix subsystem (Ubuntu) aside all the old crap instead of just being Unix
compliant and progressively drop old chunks of code as year goes by like Apple
started to do 15 years ago.

~~~
pjmlp
UNIX is oversold and if it was sold by the same price as other commercial OS
back in the day, it wouldn't ever taken over the IT market.

I appreciate the option of running other OS more open to explore the ideas of
Xerox PARC.

Also Apple just got UNIX by acquiring NeXT, with Be the music would be other.

Even on NeXT's case, UNIX compatibility, was a means to allow software into
the system, not out of the system.

No valuable NeXT application, or for that matter Mac OS/iDevices, made that
much use of UNIX APIs.

[http://www.nextop.de/NeXTstep_3.3_Developer_Documentation/](http://www.nextop.de/NeXTstep_3.3_Developer_Documentation/)

~~~
Twisell
Still I find interesting that Apple and Microsoft again choose different
strategies to try fill the gap between them and FOSS supporters: -Microsoft is
gonna include an FOSS unix subsystem -Apple for the first time in his history
is going full FOSS for Swift development

~~~
Longhanks
It's just the Swift language itself that is open source and a few libraries.
Most of the OS X layers above BSD are still closed source.

It's not " _more open "_ than C# and .NET in that regard.

~~~
Twisell
Sorry if I was wrong I absolutely now nothing about c# & .net.

Does it mean one could actually review code and fork theses languages too if
need be?

~~~
Locke1689
Certainly:
[https://github.com/dotnet/roslyn](https://github.com/dotnet/roslyn)

------
lottin
> MS-DOS’ command-line shell’s scripting language was relatively terse and
> moderately powerful, but lacked many of the richer, and more advanced
> features we enjoy in modern-day PowerShell, Bash, etc.

Nice try, but the Bourne shell, which dates from 1979, already had most of the
features commonly found nowadays in Unix shells.

------
rmm
I want to use powershell more but I am too trained to <Win+R> cmd <enter>

To do the same with powershell I need to type "powershell" within run, many
more keystrokes. I would love to just type "ps" or something short to do this.
(natively not via an alias for when im using other peoples computers)

~~~
EvanAnderson
The inability to launch an elevated process with an easy key shortcut in the
"Run" <Win>+<R> dialog has been breaking me of that muscle memory over last
few years. The <CTRL>+<SHIFT>+<ENTER> sequence to elevate a new process works
from the "Search" text-box in the Start Menu, but not the "Run" dialog.

~~~
Semaphor
You just made my life so much better. Right click->Run as Administrator was
pretty cumbersome.

~~~
EvanAnderson
That <CTRL>+<SHIFT> works on left-clicks on taskbar icons and double-clicks on
other icons, too.

~~~
ygra
It also works with middle-clicks on taskbar icons to launch a new instance as
admin.

------
basdevries
At least PowerShell is taking over as the default. Should have been changed
back in Windows 7. Copy & paste with Ctrl-C and Ctrl-V is what made me switch
to PowerShell.

------
yuhong
The name CMD.EXE actually comes from OS/2.

------
joe563323
The recent trend is to use the git shell on windows and execute bash scripts.

------
SmellyGeekBoy
What a strange writing style! Almost every sentence ends in an exclamation
point! I never realised CMD could be so exciting!

------
gcb0
unfortunately.

------
TwoBit
"Cmd has served us all well for almost 30 years now"

No it hasn't.

------
mtdewcmu
If Cmd is not going away, why doesn't MS invest in it and make it more useful?
It could learn a few things from xterm, bash, etc.

~~~
banana_giraffe
The article mentions that. Every change, no matter how trivial, in cmd breaks
some behavior that someone is depending on, or at least it feels that way.
Even fixing bugs tends to break large number of scripts in the wild.

I'd like to see a 'bacmd' or something where they could break some history
without fear, but clearly MS has decided to focus their resources on a very
different way of thinking for their new shell.

~~~
quotemstr
Bullshit. cmd has an extension mechanism specifically designed to allow for
breaking extensions [1] to the cmd command language. This mechanism hasn't
been used very much, but in principle, you could easily add new SETLOCAL [1]
commands to enable support for modern command shell features.

But cmd is in "maintenance mode", which means nobody is interested in adding
features. Powershell is the new hotness. And Powershell wouldn't even be so
bad if some of the more shameful problems were fixed --- a pipe between two
native programs should be 8-bit clean!

[1] [https://technet.microsoft.com/en-
us/library/bb491001.aspx](https://technet.microsoft.com/en-
us/library/bb491001.aspx)

~~~
ygra
It'd also be of dubious value by now. Cmd has been feature-stable since
Windows 2000, I think. Any features added _now_ (i.e. available only in
Windows 10, update.next) would not be used by anyone since oftentimes batch
files are used where you need stuff to work on pretty much every Windows
installation. (Or they are so simple that they wouldn't benefit anyway.)

------
snambi
Instead they can adopt linux and release a Microsoft Linux. Why bother about
windows?

