Bringing Bash's powerful command line editing to Microsoft Windows' cmd.exe

http://code.google.com/p/clink/

by yanovskishai • 14 years ago

131 92 14 years ago

code.google.com

slu2• 14 years ago

Looks sweet.

I currently have to use Windows at the customer I'm working for. I've installed Console which gives tabs and better copy-n-paste on Windows. See http://sourceforge.net/projects/console/

I'm not sure if clink and Console will work together, but I'll have to try it.

rbn• 14 years ago

I use console too and it's awesome. I love the tabs and the transparency feature.

7D82• 14 years ago

yea, i've been using Console2 for the last year and absolutely love it.

ot4• 14 years ago

Console2 regularly crashes on my Windows 7, and it looks like it's not actively developed.

I'm giving ConEmu a try and it looks awesome!

http://code.google.com/p/conemu-maximus5/

Scott Hanselman wrote a blog post about it:

http://www.hanselman.com/blog/ConEmuTheWindowsTerminalConsol...

daliusd2• 14 years ago

Console2 looks releases 1-2 releases per yer. Looks quite stable while not active as some other projects. Check dates here: http://sourceforge.net/projects/console/files/console-devel/...

slu2• 14 years ago

I've never had a single crash (of Console2) on my Win7.

daliusd2• 14 years ago

I have tested and clink works with Console. Actually I don't see reason why it shouldn't work with Console. Maybe there might be shortcuts collisions but I have not met yet any.

alanbyrne• 14 years ago

What's wrong with Powershell?

est• 14 years ago

starts too slow.

pjmlp4• 14 years ago

on my PC it is instantaneous, it is a matter of hardware.

SpikeMeister• 14 years ago

I have the same problem.

pygy_• 14 years ago

Yet another tool to learn.

It is definitely worth it for some people, but time is a limited resource, and others will benefit from this kind of project.

7D82• 14 years ago

as a .NET developer who sits in both Linux and Microsoft worlds, but primarily in Microsoft technologies, I must say that PowerShell is a very useful and amazing addition to Windows. I did have to learn it, but once I did, I love it.

gecko• 14 years ago

I love PowerShell dearly, and I miss it on Unix systems, but what this is trying to fix, and what still stinks at the moment, is the command-line editing situation in Console, which has nothing to do with PowerShell v. Bash v. cmd.exe.

38leinad• 14 years ago

just use cygwin

ot4• 14 years ago

I feel like cygwin manages to combine the worst of UNIX and the worst of Windows. And the commands that use the cygwin runtime are noticeably slower than the native counterparts.

Also, AFAIK there is no 64bit version yet, which for me is a dealbreaker (I often work with files larger than 2GB).

EvilTerran3• 14 years ago

I'm with you there -- I find Cygwin starts slow and unstable, and then seems to rot at an astonishing speed, to the point where it's usually unusable after I've had it installed for a couple of months.

barrkel4• 14 years ago

Almost nothing, except in-memory processing, requires 64-bit for dealing with files over 2GB. Piping with utilities is the Unix way, and it works well with files of any size in Cygwin.

Cygwin commands that run slower than Windows counterparts are typically those that are syscall heavy, where those syscalls are significantly different on Windows and need lots of work for emulation. The biggie is fork(); it's better by far to write scripts etc. in such a way that they stream results rather than iterate and create new processes.

So, for example, rather than write a script that converts Unix paths to Windows paths with iterated calls to cygpath -w, instead pipe the paths to cygpath -w -f -. Rather than use pipe-to-sed (like "$(echo $foo | sed 's|bar|baz|')") for ad-hoc edits, try to use shell substitutions instead (like "${foo/bar/baz}").

Another thing that can be slower in Cygwin is find, when run over very large directory trees. I wrote a wrapper script (I call it rdir) that runs "cmd.exe /c dir /b" and massages the output into a Cygwin-style format. I also have the same script written in terms of find, so that my scripts that use it work on Windows, Solaris, Linux and OS X.

But I have to say, the biggest limiting factor in me solving ad-hoc problems is composing the tools available, rather than the actual runtime speed of the tools themselves. Having all the Unix tools available makes my life far easier in this respect. They could be even slower, and I wouldn't mind, because I would still be saving lots of time compared to what Windows provides; and my scripts usually also work on all my other systems running different OSes.

PowerShell doesn't even support simple fork-join like bash does trivially:

    for x in {1..10}; do (sleep $x; echo $x) & done; wait

I use this idiom a lot when dealing with lots of multi-gigabyte files. PowerShell is mostly useful to me when I need to access Windows-specific stuff that Cygwin doesn't do well, like WMI.

jebblue• 14 years ago

When I sometimes have to work in Windows (which really makes no sense at those companies since the products I build 99% of the time run on Linux); Cygwin makes Windows usable.

projectileboy• 14 years ago

Is this different from Unix Utils? Every gig I've ever been on where I'm forced to use a Windows box, first thing I do is load the Unix Util exes into some directory and add it to the path. http://unxutils.sourceforge.net/

pudquick• 14 years ago

If you like unixutils, you might like GOW a bit more:

https://github.com/bmatzelle/gow/wiki/executables_list

https://github.com/bmatzelle/gow/wiki

Kept up to date, every .exe (once installed) is self-contained (no external .DLLs) and portable to just about any Windows box I've run into.

No Cygwin or MinGW installation required.

Bash is actually available in the list (albeit an older version) if you really wanted "bash on Windows"

mih• 14 years ago

Thanks. I used to use GNUWin32 (http://gnuwin32.sourceforge.net/), but this seems like a good alternative.

m_rcin• 14 years ago

Are you sure it's kept up to date?

The initial github commit has comment "Initial import of the code I developed back in 2006. Nothing has been changed since then.", and nothing has been changed since that commit (with exception of docs, Gow.nsi and gow.vbs files).

malkia4• 14 years ago

There is also busybox for Windows - https://github.com/pclouds/busybox-w32

Graphon2• 14 years ago

Yes, it's different. UnxUtls gives you grep, tar, tr, gzip, and etc. Clink appears to give you shell command completion and history completion.

They are complementary.

antidoh• 14 years ago

Which is nice, because you get fine grained control over which bandaids you put over cmd.exe. This basically gives you readline and not much else, and you don't have to install multiple possibly overlapping bandaids to get it.

gouranga10• 14 years ago

I've switched to powershell ISE on windows (shipped with it) rather than cmd hosted powershell. Does the job!

omaranto• 14 years ago

Is it worth installing .NET 3.5 to run the ISE? I use Powershell but only have .NET 4 which runs it just fine. I'm a little surprised that ISE requires 3.5.

gouranga10• 14 years ago

It doesn't make any difference. It required 3.5 as win7 shipped with that framework. You may actually have 3.5 installed already. Check for the following dir: c:\windows\Microsoft.net\framework\v3.5

If it's there you have it already.

noveltyaccount3• 14 years ago

Have you tried the ISE on Win8 yet? It gets some nice upgrades around intellisense.

gouranga10• 14 years ago

Not yet - will fire up my vm later. Thanks for the tip!

ehosca2• 14 years ago

Do yourself a favor, learn PowerShell if you have to work on Windows. http://technet.microsoft.com/library/bb978526.aspx

Graphon2• 14 years ago

While powershell is a valuable and interesting option, the problem with it is that it changes the basic metaphor.

For 40 years unix shells and their descendants and derivatives including cmd.exe have used files and text streams as the metaphor for interconnecting processes. Powershell changes that, and it means the output of one command goes to the input of another command as "objects".

This can be powerful, but it is also very disorienting. Which means it can be hard to learn to do even basic things in powershell, things that would take only a pipe or two and a couple unxutls programs in cmd.exe.

In cmd.exe, easy things are easy and hard things can be really hard. In powershell, hard things are hard (as opposed to "really hard") and easy things are hard.

gouranga10• 14 years ago

I'm not a fan of powershell but I have to use it in my line of work.

The only thing that I find sucks is that the pipeline is slow as snails. For example, an svnadmin dump piped to a file which takes 8 mins in cmd.exe takes 14 hours in powershell...

Apart from that it's bearable!

jules• 14 years ago

I do only easy things with Powershell and I found it much nicer than classical shells. It's more consistent in the command names and parameter passing. You also need to learn far fewer commands, because Powershell follows the Unix philosophy of small tools that do one thing well much more than Bash+Unix tools. For example if you do "ls" then you get a table where one of the columns is LastWriteTime. Want to sort by that column? "ls | sort lastwritetime". This works without hassle because ls returns a list of objects, and sort sorts a list of objects by a given property, instead of serializing everything to text that would need to be parsed first. I'm sure that Unixes' ls has an option built in to ls to sort by that column, but off the top of my head I have no idea what it is, and many commands that output lists of things do not have that option.

You even get autocompletion across commands: if you type "ls | sort _" where _ is the cursor, then you get a list of properties that you can sort objects returned by ls by (LastAccessTime, LastWriteTime, Extension, etc).

bobson67• 14 years ago

> it means the output of one command goes to the input of another command as "objects".

Only if both commands support objects. If one of them doesn't then PowerShell just deals with text. I've sent the output of PowerShell commands to perl scripts and GNU utils without any problems. It just worked. I'm still a powershell newbie, and this has made it easy for me to learn it while still using what I know.

slowpoke3• 14 years ago

Do yourself a favor and don't lock yourself even more into the Windows environment if you, for whatever reason, have to work with it.

Permit2• 14 years ago

May I ask why?

soldermont001• 14 years ago

Except you can't change your default shell to it, and expect your system to work. You also can't expect that it's installed by default.

alttab4• 14 years ago

Powershell is retarded. Microsoft uses it for their "web services" too which defeats the entire fucking point of it being a web service.

alttab4• 14 years ago

Not sure why I'm getting hate for this. If you want to write a client for MSOffice365 you have to be on a Windows machine... and its a web-based "cloud" service. Makes no sense if you ask me.

malkia4• 14 years ago

Or just use Far Manager - http://www.farmanager.com - it's Midnight Commander, Norton Commander type of program.

shortlived4• 14 years ago

I've watched numerous Russian colleagues use it and it does not look appealing. These same colleagues do not seem to understand the power of a real *nix shell. You end up doing less typing if you really know your shell and how to pipe etc.

malkia4• 14 years ago

You can run cygwin shell from FAR, or any other shell. Seriously.

Think of Far Manager as Midnight Commander, more or less.

Bjartr• 14 years ago

Why use this over a cross-compiled version of Bash?

Bringing Bash's powerful command line editing to Microsoft Windows' cmd.exe

Related Stories