
How bad is the Windows command line really? - momo-reina
http://blog.nullspace.io/batch.html
======
byuu
It's really, really, _really, really_ really bad.

It doesn't even have a logical history. Despite having used it for many years,
I still don't understand why when I type one command (eg make), and then
another (eg out.exe), I have to toggle between pressing up or pressing _down_
from the new command-prompt to access the previous commands.

I can't make the window more than 80-characters wide dynamically. (I don't
want to change settings and restart the program to get the width to change.)
So any time I want to copy and paste one of the infamous wall-of-text C++
template errors, I have to waste a lot of time reformatting the text.

Copy-and-paste as well is just complete garbage that takes forever.

I have to dump batch files into a folder in PATH because there's no alias
support nor .profile startup script.

I can't color-code the prompt separately for visibility. There's no tab-
completion. There's no shell escaping backticks. On and on.

Batch scripts are just hopelessly broken. It really feels like we're abusing
the hell out of them to do things they were never intended to do. The language
is closer to Malbolge than C.

PowerShell is a whole other can of worms. I don't care for it either, but
that'd be a separate discussion.

Bash on Windows sounded promising, up until "Windows 10 only" and "doesn't
play nice with the regular Windows environment."

~~~
sixothree
I agree it's pretty bad. But...

> I can't make the window more than 80-characters wide dynamically.

Windows 10 fixes this. You can resize the window and it wraps text better than
any other terminal out there.

> Copy-and-paste as well is just complete garbage that takes forever.

Turn on Quick Edit. Now drag to select and right click to copy.

> There's no tab-completion.

Tab completion for filepaths works quite well for me.

~~~
byuu
> Windows 10 fixes this. You can resize the window and it wraps text better
> than any other terminal out there.

Don't want to derail with Windows 10 arguments, but for me, that's a total
deal breaker at this time. But thanks for pointing it out! Now if I find out
Windows 10 can handle LF-formatted text in Notepad, I'll have to check and see
if Hell froze over :P

> Turn on Quick Edit. Now drag to select and right click to copy.

It's not just having to go to the menu to click edit, it's that it bounds
selections as a rectangular box when you paste the results. I also don't like
the way quick-edit is so quick to select white blocks just by clicking in the
window without dragging. Then to get rid of it, I have to right-click and kill
whatever was in my clipboard. A bit OCD there, but ... I like bash a whole lot
more. Normal text highlight, middle-click to paste what was highlighted
elsewhere, and it's formatted properly. This is especially important when
copying those 200-character long C++ template error messages.

> Tab completion for filepaths works quite well for me.

...... indeed there is. How in the world did I miss this?! Very sorry, I can't
edit the parent post to fix this now.

~~~
mappu
_> Don't want to derail with Windows 10 arguments, but for me, that's a total
deal breaker at this time._

I'll bite. What's holding you back? Ever since 7 / 8.1 got telemetry
backported in, they're on equal footing with 10 from a privacy standpoint. I
guess you could cherry-pick out which windows updates you want to install, but
that's frankly unsustainable.

You may as well get the new WDDM, the new DirectX 12, the new virtual desktop
support, the new command prompt, and all of that.

 _> if I find out Windows 10 can handle LF-formatted text in Notepad, I'll
have to check and see if Hell froze over :P_

It doesn't, and it hasn't :P

Love your work by the way. bsnes/higan is a significant contribution to the
human race.

~~~
byuu
> Ever since 7 / 8.1 got telemetry backported in, they're on equal footing
> with 10 from a privacy standpoint.

I primarily run FreeBSD. But when I run Windows, it's a fresh SP1 install with
updates disabled. I am not worried about the safety of it. I have a firewall,
behind a router, and I don't install much of anything. I just use Windows for
chatting and browsing online, watching streaming media services, etc. If
something were to become compromised, I'd just wipe the drive with nothing of
value lost or stolen in the process. I have another Windows box that doesn't
even have internet access that is solely used to build and release Windows
ports of my software.

Telemetry is part of it. I also find the interface ugly as sin (duller than
Windows 3.1), don't like how bloated it's becoming (Metro tiles, Cortana,
etc), don't like how difficult it is to disable updates, etc.

To be honest, if I had my way, I'd be on Windows XP (classic mode) still for
what I use Windows for. The main draw to 7 was that XP's 64-bit drivers were
mostly garbage or just plain unavailable; and I have lots of RAM and like the
speed boost for 64-bit software too much.

> Love your work by the way.

Thank you very much! But ...

> bsnes/higan is a significant contribution to the human race.

I don't know about all that o_O'

At the end of the day, it's just video games.

------
brudgers
In computing, "batch" connotes long running processes in addition to
"script"'s connotation of collapsing multiple commands into a single one. The
seemingly redundant parsing by the Batch interpreter is a feature, not a bug.

1\. The parser allows modifying a .bat file during its execution and having
those changes execute without restarting the Batch interperter. [1] This is in
keeping with the rationale for batch processing -- facilitating serial
execution of computationally expensive operations.

2\. The Batch interpreter allows self modifying code.[2] In the early 1980's
when Batch was designed, sophisticated COBOL programmers might have felt right
at home. Lisper's were probably more hit and miss.

This is a case where historical context is useful. Today, it might perhaps be
worth mentioning Powershell in a discussion of the Windows command line. Batch
was the DOS command line and exists in Windows for evolutionary reasons.

In the days when abundant RAM and fast CPU speeds were prefixed with "mega"
and distributed computing often happened at BAUD rates, not restarting a
process was a big deal. More importantly, then as today, the execution speed
of the batch interpreter was not a critical section of a batch process.

[1]: [https://stackoverflow.com/questions/906586/changing-a-
batch-...](https://stackoverflow.com/questions/906586/changing-a-batch-file-
when-its-running)

[2]:
[http://swag.outpostbbs.net/DOS/0019.PAS.html](http://swag.outpostbbs.net/DOS/0019.PAS.html)

~~~
j2kun
But bash was around in the 80's, too, right? And it didn't seem to need those
features. How did bash users get around your claimed need for this?

~~~
userbinator
Bash first came out in 1989, but the typical shell of the time was sh, and it
ran on Unix systems with more memory, storage, and CPU power than the typical
PC. Thus it's no surprise that the sh family started with more features, while
COMMAND which cmd evolved from was extremely minimalistic. DOS 1.0's
COMMAND.COM was just slightly more than 3 _kilobytes_ and didn't have
conditional nor goto statements:

[http://www.os2museum.com/wp/dos/dos-1-0-and-1-1/dos-1-0-dir/](http://www.os2museum.com/wp/dos/dos-1-0-and-1-1/dos-1-0-dir/)

[http://www.os2museum.com/wp/dos/dos-1-0-and-1-1/](http://www.os2museum.com/wp/dos/dos-1-0-and-1-1/)

~~~
Roboprog
Even if the *nix machine was no bigger than a PC (e.g. - Xenix on '286; BSD on
a PDP-11), it could still swap out processes, vs sharing a single real memory
space.

But as you said, this allowed (at least the illusion, on some machines) more
total memory to work with.

~~~
brudgers
In the 1980's a 80286 would have been toward the high end of x86 systems. The
80386 started shipping in bulk in 1986 and the Compaq DeskPro 386 and IBM PS/2
Model 80 were well north of $5000 in 1987 and the "prosumer" PS/2 was the
Model 60 with a 80286 when the line was released.

Even in the late 1980's 8088 based systems were pretty typical and why IBM
included the PS/2 25 and 30 in its initial product line.

~~~
Roboprog
I remember using (sharing!) an XT (8088? 8086???) at work in 1985. One good
thing about the 386 in 1986 was that it made the price of 286 (AT/clone)
systems come down. I almost never saw an XT after 1986. We started seeing
quite a few more clones (Compaq, etc) about that time, as well.

Which is of course a big tangent off of "why/whence command.com & .BAT files"
:-)

OS/2 and Windows were a big deal in virtualizing memory use in PC land, with
widespread Linux use still "a few years" in the future. (and effective
adoption of NextStep even further out)

~~~
brudgers
I think the 80386SX was also a factor in lower 80286 prices after the 386DX
came out. Those systems were really popular.

When I bought the Amiga 500 in 1988, 8088 Turbo machines were still the entry
level clone system. My vague recollection of the consumer and small business
market was that that obtained for a couple of more years.

------
elchief
Powershell is garbage. .Net does utf8 by default but powershell, built on
.Net, manages not to.

Try type utf8Encoded.txt > out.txt in cmd.exe and posh. Cmd works and posh fs
it up.

And after you do figure out utf8 encoding in posh, it'll always add a BOM just
to screw you

~~~
stephengillie
This has frustrated me to no end. I've given into using WriteAllLines as a
work-around.

[IO.File]::WriteAllLines($filename, $content)

(from [https://stackoverflow.com/questions/5596982/using-
powershell...](https://stackoverflow.com/questions/5596982/using-powershell-
to-write-a-file-in-utf-8-without-the-bom))

~~~
lqdc13
I get OOM with larger files even when they should fit in memory.

Powershell is like a poor Java/C# interpreter instead of a quick and dirty
shell.

------
itaysk
Agree about Windows command prompt being lame compared to bash, but I really
find PowerShell amazing, even more so then bash. If you look at all the recent
(even not so recent) products from MS, it is clear that PowerShell is the
shell for Windows, and not batch. I didn't get the cure for polio analogy
that's in the article but I really think anyone that's comparing shells should
compare with PowerShell.

~~~
nailer
You're on Hacker News. Most people who say they hate powershell have done so
little posh they don't even know 'select' or 'where'.

~~~
vetinari
Nobody starts using posh just because some new cool thing in the shiny new OS.

My first impression of it? It went like this:

Task: you need to connect to Hyper-V VM console via Remote Desktop.

Hiccup: for that, you need to know it's GUID. How to find it out? Just run
this handy posh script...
([https://blogs.msdn.microsoft.com/virtual_pc_guy/2014/11/25/u...](https://blogs.msdn.microsoft.com/virtual_pc_guy/2014/11/25/using-
rdcman-v2-7-to-connect-to-a-vm/))

Another hiccup: That script does not work, it needs some library that's not
loaded by default. Try to find out how.

Another hiccup: It does not load, because it breaks some policy, that's off by
default. Investigate, what to do.

How it ended: forget it, I have better things to do than solve problems with
Powershell. Look into VM files and find out, that it's one of the GUIDs there.

Result: Won't touch posh again and anyone singing about its virtues is getting
promptly ignored.

Maybe it's not fair to Powershell, but the first impression counts.

~~~
nailer
Totally agreed the default policy thing (you can't run scripts until you allow
it) can be a nasty shock, especially to folk (like me and everyone else here)
coming from Unix.

OTOH, you'll spend way less time scraping stuff for regexs and actually just
asking posh for fields. It's really, really worth learning.

------
EvanAnderson
I get perverse joy out of using the Windows CMD.EXE shell (and the earlier
COMMAND.COM from MS-DOS). Yes, it's tremendously crufty, idiosyncratic, and
sometimes seems down-right illogical in its behavior. Arguably, just about
anything else is better, but it holds a special place in my heart.

~~~
conceit
If I could downvote you, I would. That's probably why I'm not allowed to. :)

~~~
choosername
kill-it-with-fire kind of downvote, not a HN smug just-because-I-can kinda
downvote.

------
jasonjei
This isn't completely related to Windows command line but I thought I would
post it out here.

I was trying to run a Bash script from a Git repo mounted in a Docker
container. When running the Bash script, I kept getting all kinds of errors. I
ran the exact same script in the same Docker container on a different Linux
computer that had cloned the repo. It turns out the \r Windows line endings
(which I later normalized in Git settings) caused my script to barf.

~~~
chipperyman573
You can also normalize them using the dos2unix package, which is available on
most distros.

~~~
bluejekyll
Have the line ending wars ended yet? Apple is finally Unix \n, but most
internet protocols are \r\n as are Windows.

Though honestly, Windows just doesn't even matter any more to me, I haven't
needed to touch an MS product in years...

~~~
userbinator
[https://en.wikipedia.org/wiki/Newline#History](https://en.wikipedia.org/wiki/Newline#History)

\r\n, CR+LF historically speaking was the first, but \n, LF became dominant
because of Unix.

~~~
Jaruzel
If you break it down and view them as terminal codes (or as the spec was
designed, on a teletype), CR+LF is correct, and LF is not.

However, the inconsistencies of this over time have become really annoying. My
long term pet peeve is in VB.NET when I have to do this:

    
    
      ' This works - using the VB6 interop
      Split(StringName,vbCrLf)  
      
      ' This doesn't work - using the native .NET function
      ' because .split is only expecting a Char, and not a String)
      StringName.Split(vbCrLf)
    

Really, really annoying.

~~~
Retra
Why would you want strings to be formatted using terminal codes? It's just
textual data. It has nothing to do with terminals, other then the fact that
terminals need to handle text. I see little reason that text should have to
handle terminals.

With that said, CR+LF is just inefficient, since doing both of those tasks
together is what is overwhelmingly desired for a newline.

------
kmiroslav
Personally, one of the reasons why I fell in love with Ruby 10+ years ago was
because I realized I could use it instead of CMD or bash to write all my
scripts from now on. Regardless of the platform. Obviously, this applies to
Python as well if that's more your thing.

I've never gotten into PowerShell but I have absolute respect for the concept
behind it, and how much more advanced it is than any shell you can find on
UNIX. Think about it: instead of piping several commands through an
unspecified string protocol that varies between each command (essentially what
UNIX does), you are now piping real language objects in a uniform binary
protocol defined by the shell itself.

~~~
bad_user
> _you are now piping real language objects_

Which is in fact a bad idea, because in order for stdin to accept objects and
stdout to output objects, now those commands have to be powered by PowerShell
and .NET. In other words you're in a very finite and closed environment that
does not interoperate with the outside world.

You know, love or hate Unix, but the fact remains that this family of
operating systems, including its command line, has survived the test of time.
And it has done so because it has at its core a set of philosophical
principles. And one of those is that programs that handle text streams are
preferred, being highly interoperable, as text is a universal interface [1].
And you know it's funny how people loathe Unix, but at the same time
rediscover its principles (and often implement them badly) again and again.

[1]
[http://www.faqs.org/docs/artu/ch01s06.html](http://www.faqs.org/docs/artu/ch01s06.html)

~~~
adzm
Those who don't understand Unix are doomed to repeat it.

~~~
tbyehl
Those who haven't read the Monad (Powershell) Manifesto[1] are doomed to keep
repeating Unix's failures.

[1] [http://www.jsnover.com/blog/2011/10/01/monad-
manifesto/](http://www.jsnover.com/blog/2011/10/01/monad-manifesto/)

------
alkonaut
It's absolutely laughable. But I've almost come to see this as a feature -
It's so terrible that no one relies on it or uses it. Bash in my opinion is
overused.

------
mschuster91
I usually write shellscripts in PHP. Works pretty good, and PHP is by far
easier to write than either bash scripts or Windows shell script - not to
mention that one single syntax can be used for both OSes, which is nice when
you do development on both Linux and Windows, and even nicer when you're also
developing on OS X which ships a horribly outdated bash (and other coretools).

~~~
nacs
I am by no means a PHP hater (I do some PHP dev for work) but PHP not only has
multiple versions (4, 5, 5.3) but has a ton of modules for everything (curl,
mbconv, openssl, etc) that have to be setup the same way for you to get the
same behavior across OSes. Not sure it makes a great shell script for that
reason.

~~~
mschuster91
On systems I control, I currently stick with the latest PHP5 release,
unmodified - either the distro maintainer version, or in case of Windows, the
official binaries.

Configuration customization isn't really needed, only the usual date.timezone
to get rid of the warning (and hell, this is annoying! can't PHP just use the
OS-provided time zone?!), and in extremely rare cases the memory limit and
max_execution_time.

------
tr1ck5t3r
Its good enough to bypass UAC & AV and run whatever you like.

You dont even need to give your software a ".exe" extension to run code.

Just rename a program removing its .exe extension, then call it from the
command line. It will run!

Its perhaps better to compare dos BATch files with bash.

------
agumonkey
just in case,
[https://mridgers.github.io/clink/](https://mridgers.github.io/clink/)

only 600kb to enjoy your sanity back

------
ams6110
I honestly feel like I am missing something. What is the current excitement
about bash on Windows? It's been available (and something I commonly use) via
cygwin for years. And cygwin's bash can run .exe binaries.

~~~
tacos
Cygwin is quite slow due to problems emulating fork (large builds take
forever!), plus the package support is spotty. I'm excited because I can
eventually ditch Cygwin and VMs for much of my Linux compatibility testing and
cross-platform work. And I'm glad Microsoft is finally putting some effort
into this long-neglected area.

For the moment, I'm still stuck with Cygwin, shaking my head a bit too.

------
adzm
I've just spent way too much time trying to get utf8 to work well on the
command line, ugh.

------
b34r
Why even make batch available? Just make PowerShell th default and be done
with it.

------
tacos
There are, of course, choices beyond Bash, Batch and PowerShell.

I'm a Microsoft fanboy and I find Python far more structured and faster than
any of the above for anything beyond the most simple shell scripts. (If only
the inventor of PowerShell had spent ten minutes outside the Microsoft
ecosystem before locking himself in a seafoam green office for two years...)

Doesn't solve the IT admin scenarios PowerShell is good for but I don't go
there. And if I did, I'd use C# anyway. No need to learn a new language to
loop and call objects, that's solved.

With the .NET Core stuff, I'm using C# and Microsoft.DotNet.Cli.Utils and the
end result is briefer and saner than Python argparse, and file operations work
great cross platform. Less issues than even Python, plus I can use LINQ to
sort and remove dupes. Handy.

As for the "Windows command line" (cmd.exe) well, it still sucks. Console2
plus Clink and ... well, you'll still miss zsh on cygwin or what just works
out of box on Mac... but, hey, it's a start.

------
dingo_bat
The cmd.exe on Windows 10 is a significant improvement from older versions. So
much so that it has become actually useful now.

~~~
daigoba66
I think you're thinking of conhost which is the console window program used to
run cmd.exe, PowerShell, et al. That has some new features. But I don't
cmd.exe itself saw many, if any changes in Win10.

~~~
dingo_bat
One of the biggest (maybe silly) change is that cmd is fully resizable. I
think Powershell was already able to do this in Win 7. So I think apart from
the changes to conhost, cmd itself has been upgraded in some ways.

------
sklogic
Unreadable on mobile

~~~
brudgers
Noticeably faster than average on desktop. There's no silver bullet.

~~~
chickenfries
Setting a max-width on the body text would make this incredibly more readable
on narrower viewports. At 636kb and 48 requests, this page probably isn't as
"minimal" as you think it is. For example, should there be any reason you can
read the disqus comments at a reasonable size but not the body of the post?

~~~
brudgers
I tried it on mobile. It still loaded fast. As with many pages, Firefox Reader
Mode improved the experience. Though for me, the bulk of the improvement comes
from text formatting, part of the improvement is hiding blog comments, ads,
email signups, etc.

Anyway, my experience is that touching Firefox's reader-mode icon in the
address bar is usually faster than a boatload of formatting logic; produces
more readability than a website's general optimization, and bypasses all the
ancillary crap that people concerned enough to optimize for mobile tend to
add.

~~~
sklogic
Fast-schmast, I do not care, cannot read anything at all (chrome on android).

------
YeGoblynQueenne
tl;dr: batch will steal your soul and sell your kids to the Great Old Ones'
cultists. Bash is meh (the author doesn't really know much about bash). User
Powershell. Save the world.

... and it's all true.

