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."
> 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.
With readline-style editing, as in bash, when you go back to an earlier command and re-run it, it is added to the end of the history and your "position" in the history is reset to the end. So if you want to go back to an earlier command again, you always hit "up".
In cmd.exe, when you go back to an earlier command and re-run it, you are simply going back to that earlier position in the history. When you run it, your location in the history is now immediately after the command you just ran. So to run the following command again, you now hit "down" rather than "up".
I think it's pretty logical and I actually quite like it (after the first half an hour of familiarisation, each time I have to use it). It's just different.
I also genuinely like PowerShell, but I'm with you on everything else.
> I think it's pretty logical and I actually quite like it (after the first half an hour of familiarisation, each time I have to use it). It's just different.
Interesting! I never realized the logic behind it, thanks for expanding on it.
I definitely don't care for it at all. Much easier for my mind to think of the list of previous commands as a straight list, than trying to conceptualize 'where I am at' in my list of previous commands, and how executing a new command would then jump me somewhere else entirely. But I'll respect your difference of opinion.
To expand on this. As a Unix user with decades of experience writing shell, I find it easier to write a shell script than a PowerShell one for any given job. But I am a lot more confident that the PowerShell one will work correctly.
I take care with argument handling and the like in my scripts, but I still feel that testing a shell script with a specific set of inputs only really tells me whether it works with that set of inputs. It's almost certainly possible to craft an alternative set of inputs that will break it. I don't feel that way about PowerShell.
On the other hand, I do find it much easier to reason about performance with shell scripts. Their simple streaming structure parallelises well and the individual commands have generally predictable performance and scaling characteristics. I'm a lot less confident about that aspect of PowerShell.
"Console aliases are used to map source strings to target strings. For example, you can define a console alias that maps "test" to "cd \a_very_long_path\test". When you type "test" at the command line, the console subsystem expands the alias and executes the specified cd command.
To define a console alias, use Doskey.exe to create a macro, or use the AddConsoleAlias function."
If you do not specify /d in string, Cmd.exe looks for the following registry subkeys:
HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor\AutoRun\REG_SZ
HKEY_CURRENT_USER\Software\Microsoft\Command Processor\AutoRun REG_EXPAND_SZ
If either one or both registry subkeys are present, they are executed before all other variables."
"Iterating and file parsing
Use file parsing to process command output, strings and file content.
[…]
for /F ["ParsingKeywords"] {%% | %}variable in ('command') do command [CommandLineOptions]"
Good UI? I've seen better. It also doesn't affect the conclusion that the cmd shell is bad, but the functionality does exist in some, often weirdly limited, form.
The quick edit copy is ridiculous, it inserts newlines between one line of output if it wrapped instead of obligingly copying the content as it was sent to stdout. The selection mechanism makes nearly no sense, why would I want to select text by a rectangle?!
> 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.
>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.
> 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.
Let's say you want to copy and paste something from an earlier command line entry and put it in a new command line entry:
% set -o vi
% # hit ESC to go into vi cmd mode, hit k a few times until
% # you get to this old command in your command history:
% longasscommand -with -params -i super.dont -w ant2 -type in -again
% # you want just the stuff from -params to ant2, so you
% # type "f-n" to get the cursor to -params, then "yf2"
% # to copy everything from there to -w ant2
% # now you type j a couple times to go back down to
% # the line you were working on:
% longasscommand -with -oh jesus -not this.shit -again
% # now you hit "f-nn" to put the cursor on the -not
% # type "dW." to get it just so:
% longasscommand -with -oh jesus -again
% # now you're ready to paste in your copy after jesus
% # so you type p, and it's inserted where you left the cursor:
% longasscommand -with -oh jesus -params -i super.dont -w ant2 -again
You can use screen or tmux to copy and paste from anything on the screen, including using the mouse. It's really out of the purview of bash, tho.
Really handy tools on the Mac are pbpaste which sends any text in the system clipboard to stdout and pbcopy, which you can prolly guess at.
There's an anti-flamefest delay on comment threads: you can't reply to comments younger than a few (5?) minutes. However, if you go to the comment directly (click on the timestamp next to it), you do get the option to reply immediately.
I still don't understand why [..] I have to toggle between pressing up or pressing down from the new command-prompt to access the previous commands.
It is because the shell history has its own completely invisible cursor, and the cursor is not reset after a command. So when you press <up> three times, then press <enter>, your history cursor is still at -3 (actually, -4). If you then want to move to command -2, you need to press <down> instead of <up>.
The real fun comes when you edit commands in your history (so press <up>, then edit the command line). I'm still not quite sure how Microsoft handles that.
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.
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:
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.
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.
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)
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.
bash came out in 1989. The Bourne shell it's backwards compatible with is from 1977. But both were designed to run on Unix on multi-user multi-process machines. DOS batch language was designed to run on a single-user single-process machine. There's a reason they used to make a distinction between "minicomputers" and "microcomputers".
> DOS batch language was designed to run on a single-user single-process machine.
This. My preferred explanation for the difference between Unix and Windows for a long time has been "Unix assumes a lot of people are doing different things on one computer, all at the same time. Windows was designed with the mental model of a calculator."
I apologize for writing in a manner that would mislead someone into believing that I claimed that self modifying code was a need for anyone, let alone systems programmers. It's all Turning complete, even if that completeness comes complete with a tarpit.
To a first approximation, I'd expect that 1980's Unix programmers would generally be working in environments more accepting of restarting a batch process when there was an error in the code, i.e. significantly less likely to hold a clerical or secretarial "TCP report" job in a regular commercial office. Though that split has become less likely, it's still pretty uncommon for a computer user with little control of their work environment and deadlines to be using *nix rather than Windows.
In the Savings and Loan recession I had one of those jobs with unpaid overtime and an employer who was comfortable abusing it. I'd start a batch print job and go home. When I came back next morning picking up the paper off the floor was pure pleasure relative to baby-sitting the machines until midnight or more.
I remember when I learned that command.com kept the current .bat file open when running it, rather than reading it into memory (like most other interpreters that I used or learned at school). We had a client on a Novell network with a menu program that generated .bat files to start the program selected, then restart the menu program. This turned out not to work very well on a multi-user network, as user A would exit an app, and continue running the .bat at some offset, which user B would now have caused to have different content, and probably not even a line break at said offset into "THE" file.
Easy enough to fix by having the menu program put the run script (.bat file) into the Novell equivalent of each user's home directory, but it was a real WTF moment at first :-)
No doubt the result of adding another layer of complexity: "type" in cmd is basically Unix cat, it just reads the file and writes it to standard output byte-for-byte. PS probably does some hidden encoding-autodetection and attempts to perform translation, but doesn't always get it right.
You can see the difference in philosophy here, cmd (and bash, to a certain extent) are simple and don't try to do sneaky things silently, even if it means you might have to do a little more yourself e.g. performing character set translations explicitly. The behaviour is straightforward and predictable. PS attempts to be more "user-friendly" by doing some hidden conversions presumably so the user doesn't have to explicitly do character set translations, and when it works it works well; but when it fails, it fails spectacularly.
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.
The worse thing about PowersHell is its syntax and OOP-ifying of everything, even if it doesn't really need to be. The naming and general syntax reminds me of this:
I don't deny that it is much more powerful than cmd, but it feels a lot like "emacs rather than vi" in its design, and I much prefer the latter (which would be more (ba)sh-like.)
Powershell the language is ok, Powershell the interactive shell is still lacking. Here's what I still need:
* usable tab-completion: scrolling through all available cmdlets is a poor substitute, and usually increases my keypresses instead of decreasing it.
* workable history editing: if I edit a previous command, I must remember to never use tab completion again, because pressing <tab> halfway in a command erases everything following the cursor
* consistent interface: In a powershell shell window, I can use left mouse button to select and copy, right mouse button to paste. In command shell window, I must use right mouse button to select "Mark" in context menu before even left-mouse selection works. In powershell ISE, left mouse button selects but does not copy, right mouse button still opens a context menu.
I use PowerShell ISE 99% of the time I write PS, so I don't experience any of these.. but valid suggestions, should go on the PS \ commandline uservoice.
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.
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.
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.
I was recently reading about OS/8, which happened because I have become interested in SIMH, and I was surprised to see how similar some of its commands are to those from DOS (which in turn copied CP/M). It was interesting to see the ASSIGN command on another OS.
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.
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)
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.
Git for Windows asks during installation if you want to replace your Windows line endings with Unix-style. You can have it replace LF with CRLF on checkout and revert on commit, or you can just have it do the revert (swap CRLF with LF) on commit and not do the first replace. Or you can just leave everything as-is.
Interestingly, when manually making a multi-line string in Powershell, only the LF character ( `n ) is needed to make a new line. Using CRLF ( 'r'n ) gives identical behavior in most strings.
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.
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.
It interoperates just fine. That's what's great about powershell, when you're working with objects on the pipeline you have a ton of power at your command, and you can write very expressive code that is compact. But at the same time, outside of that context it's just plain text. It's win/win.
If we wanted an OO shell we'd be using one. It's not like Unix has a shortage of interpreted languages. The simple fact is that these languages are too high-level to be even remotely useful as a system shell.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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?
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.
Perhaps someone felt that the page layout was far enough off topic as to be a distraction or otherwise reduce the quality of the discussion.
Personally, I've found treating unexpected downvotes as editorial feedback on the quality of my writing helpful. I just assume that:
1. I didn't make my point clearly
2. My comment was low quality
3. Someone just disagrees with the point
In the first case, I edit or delete it. In the second case I just delete it...except in those cases when I deliberately make a low quality comment knowing it is likely to attract downvotes. The third case reduces to the other two in practice, though not so much in logical theory.
Despite being interested in this topic, I simply could not even read the article. Guess it is a legitimate contribution to a discussion to warn about this issue.
Right, because HN is the customer service department for the site hosting the article that somebody submitted a link to. And because "unreadable on mobile" is such an informative statement that contains so much useful data about why it was hard to read and what it was hard to read on. Surely you weren't downvoted for those reasons. Nah, it's just HN being HN.
They did pass it by, and it was down-voted for its irrelevance to the vast majority of users. Then you went and complained about down-votes (with a dismissive insult, no less), like that was an acceptable response.
If you make a post that most people don't need to see, then don't worry about the down-votes. When you're getting down-voted for writing something most people do need to see, then there's a problem.
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.
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."