It's ConEmu with a modified config file !!! Also .....don't want to be negativist...but Monokai and portable mode have been part of ConEmu since.....forever.
Again....maybe it's just me....but why try to "spin up" a ConEmu config file as ...something else instead of just ...you know...show the world a customzied ConEmu ?
Then there is clink and msysgit and (not yet published) git integration, I am working on integrating some package manager. I will try to include any software that I find helpful.
No this is not coding project. This is a project to bring something usable and nice to people without having to read yet another "Check out my setup". It is like oh my zsh, or some kind of dev-kit.
## License
All software included is bundled with own license
The MIT License (MIT)
Copyright (c) 2013 Samuel Vasko
Permission is hereby granted, free of charge, to any person obtaining a copy
People can think that the whole package is MIT when it is certainly not (there's GNU inside)!
You have to put all the licenses of the parts you distribute in the same file where you put your license. You have to specify in that same file by names which parts are covered with which license. If you have Firefox, type about:license. You'll get a huge file where every license is precise what covers (only small selection here):
So far, strictly worse than Console2 in everything I've tried. In particular ncurses apps in an ssh session render terribly no matter what I set TERM to. "ansi" works the best, but still I find myself hitting C-l to get rid of garbage regularly.
Nice idea, but I was disappointed that it actually was some software that I probably tried and could not use (ConEmu and I can't remember why...). Maybe you could explain this new attempt?
(edit: mentions Conemu on the frontpage.. my bad)
BTW, why don't we have a bash in Windowsland? What are the limitations of the underlying OS that make it hard?
Since no one's actually answering your question, focusing on useless pedantics instead, I'll do it:
The reason Windows does not have a decent virtual console, like OSX and Linux do in the form if iTerm, xTerm, gnome-term etc has to do with the way the console works in Windows.
The Windows console is very tightly coupled with a win32 system library, both its functionality and the way it behaves graphically (to for example resizing) are defined in that single place.
This practically means that most attempts of making it better in some way proxy to a hidden view of the original console. I think ConEmu works like this.
To truly make a better console on Windows, the links to that system dll would have to be hijacked from the processes that are launched in your shell, and replaced with references to your better alternative. Obviously this could be a fragile thing, and for some reason I know of no project that's made any headway in this.
I have tried the latter route myself for a little while, but after uncovering how complicated it would really have to be I decided to go do something else.
Perhaps I missed something. What does the Windows console subsystem have to do with a program that interfaces bash with a VTxxx emulator? It's not hard to make a scrolling multi-line text field that also accepts and passes along keypresses to another program.
If I read it correctly, OP isn't looking to replace CMD or the Windows Console. It seems that he's wondering why bash is so useful, but it isn't bundled with Windows.
Well, if you take his comment literally then yes, but it would not be a very interesting question because it's quite easy to install bash on windows and use its nice features. And there's powershell which fits better in the Windows ecosystem.
I read it as the question that has a much more interesting answer: Why doesn't Windows have a good terminal? And the answer is, it's no use making one because the Windows console subsystem, the one that is the de facto standard, is so badly designed that it's near impossible to write a good terminal for it.
> [Windows doesn't have a good terminal because the Console Subsystem] is so badly designed that it's near impossible to write a good terminal for it.
Errm, Windows has a couple of decent terminals. PowerShell and Cygwin bash come to mind.
The following I say with all the love in my heart, so please read it in that spirit:
Saying that there aren't any good terminals for Windows because of the suckitude of the Console Subsystem is like saying "There aren't any good houses built on the ocean because a good, solid concrete foundation just sinks to the bottom!". There are plenty of fine ocean-going houses, they're just made out of steel, exotic or mundane fibers, or wood.
Can you resize Cygwin bash to be wider than 80 characters? Last time, admittedly a while ago, that I tried using unixy things on Windows, I ended up exceptionally frustrated by the fixed width.
I suspect that's the "Console Subsystem" being referred to here.
It seems that with a modern Cygwin (installed within the last six months) you can. Moreover, if you perform (say) an ls, resize the terminal to a really small width, perform another ls, then resize the terminal to its previous width, the text from the first ls is restored to the screen. (I also remember this behaviour from when I regularly used Cygwin four or five years ago.)
It's been a while, so don't hold me to this, but I think there's a batch file that you get a shortcut to on your desktop and start menu. If you don't use that, you'll get the stupid unresizeable window. (Because, yanno, all of the Cygwin stuff was designed to work alongside CMD.exe, too.)
Well, ConEmu is great piece of software and it works amazingly. But the default configuration is just awful. I think the author concentrates more on advanced features and Far manager. I hate spending time tweaking something to the usable state before I can use it.
My idea was to do it simple and easy. Conemu = tmux, Cmder = gnome-terminal
There are multiple ways of getting bash on windows, MSYS and Cygwin being two of them. They perform like ass compared to bash on a real unixy operating system, because Windows doesn't have fork. Its process creation is already significantly slower even before having to emulate fork/exec semantics,
which makes things much much worse. (See: http://stackoverflow.com/a/985374/341371 )
Again, bash is a shell. This is a terminal emulator. This even provides you the option to get bash along with it in the form of msysgit which comes with bash.
I think there might be a little bit of confusion/diffusion of the separation here. This page seems to be talking about terminal emulator and shell features:
"There is simple support for aliases. They can by using alias command like alias ls=ls --color $ They are pretty much just doskeys in file /config/aliases. One per line. And make sure to handle arguments by putting arguments variable $* somewhere."*
"Shell
Shift + Up : Traverse up in directory structure (lovely feature!)
End, Home, ctrl : Traversing text with as usual on Windows
Nothing actually, but you do not have to do it yourself. There is quite a lot of configuration and so on.
But if you already have this setup, no big reason to switch.
I've just created an issue. The size difference with msysgit included seemed a tiny bit weird to me. Could it be a result of a symlink being packaged as individual files?
as much as i struggle to think of something where i would use this by design, every time i've been forced to try and use some *nix-y tools on window it has been a nightmare of cygwins and mingws... i can see the desire for this.
on the other hand i'm yet to meet one of those problems where, with a little thought and not having my hands tied, i can't remove the needless dependency and end up with a better development environment too.
