Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

code.google.com

Post reply on HN
Print view View original

21–30 of 96 posts

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

#21

Post by msluyter »

barrkel wrote: post #13
EvilTerran wrote: post #10

Earlier quoted context omitted.

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.

Cygwin doesn't rot. It doesn't automatically update, and nor does it self-configure, so there's nothing to cause the rot. I've never had problems like you describe. The biggest problem - and what I suspect is happening to you - is when you have third-party programs and utilities that interfere with Cygwin, most often by putting an older or newer version of cygwin1.dll on the $PATH (i.e. you may be using Cygwin as par…

I love Cygwin, but I have experienced what I would describe as rot. (manifested via errors on fork()). I think that's caused by things changing around it, via windows dll updates, but I don't have a lot of insight into windows' dll handling and whatnot so I don't know for sure. Also pretty sure installing new cygwin packages can cause this. Usually, rebaseall fixes such problems.

In any event, I much prefer Cygwin to the alternatives.

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

#22

Post by ot »

barrkel wrote: post #18
ot wrote: post #16

Earlier quoted context omitted.

> 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. Even ls , or wc -c report bogus results with >2GB files. less does not work even if I want to look at just the first few hundreds of lines (and "head -n 1000 | less" is a horrible workaround). > Cygwin commands that run slower than W…

Eh? What you state about ls, wc and less is directly contrary to my experience . I'm so astonished I created a 30GB test file and tested it: $ cmd /c dir k.txt Volume in drive C is CobraRoot Volume Serial Number is 02D8-502C Directory of C:\Users\barrkel\AppData\Local\Temp 2012-07-01 15:24 31,292,160,000 k.txt 1 File(s) 31,292,160,000 bytes 0 Dir(s) 142,087,471,104 bytes free $ du -h k.txt 30G k.txt $ ls -l k.txt -rw…

Thanks, that's very interesting, maybe I should give cygwin another try. Last time it was a couple of years ago and I had all the mentioned problems, then I decided to wait until a 64bit version before trying it again...

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

#23

Post by pudquick »

projectileboy wrote: post #11

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/

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"

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

#26

Post by malkia »

projectileboy wrote: post #11

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/

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

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

#27

Post by malkia »

EvilTerran wrote: post #10
ot wrote: post #9

Earlier quoted context omitted.

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).

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.

Windows lacks fork(), or at least it's not documented. To implement the Cygwin folks have to go through a lot of tricks to implement it. And one of them is rebasing all dlls to start at different addresses.

There is a tool to rebase everything, and it's usually started after install. It's possible that after you have recompiled your own apps/dlls they might need rebasing too (speaking as a cygwin user, not developer).

The only thing that I found annoying in cygwin, is that I can't use all commands from the cmd.exe, because they make sense only under cygwin. For example "gcc" is just a cygwin symbolic link to "gcc-something.exe", and when you "run it" it gives "Access denied". The workaround is to run like this: sh -c "gcc " from cmd.exe

But it might solve very hard problems, for example - redis (from antirez's depot) compiled with cygwin worked for me, and although there is much better windows version by the MSOpenTech guys, it just shows that sometimes it might be the only reasonable way. The other app that comes in mind is rsync.

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

#28

Post by mih »

pudquick wrote: post #23
projectileboy wrote: post #11

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/

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 "bas…

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

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

#29

Post by barrkel »

ot wrote: post #22
barrkel wrote: post #18

Earlier quoted context omitted.

Eh? What you state about ls, wc and less is directly contrary to my experience . I'm so astonished I created a 30GB test file and tested it: $ cmd /c dir k.txt Volume in drive C is CobraRoot Volume Serial Number is 02D8-502C Directory of C:\Users\barrkel\AppData\Local\Temp 2012-07-01 15:24 31,292,160,000 k.txt 1 File(s) 31,292,160,000 bytes 0 Dir(s) 142,087,471,104 bytes free $ du -h k.txt 30G k.txt $ ls -l k.txt -rw…

Thanks, that's very interesting, maybe I should give cygwin another try. Last time it was a couple of years ago and I had all the mentioned problems, then I decided to wait until a 64bit version before trying it again...

If I had to guess, I'd say somehow you ended up with text-mode mounts in your previous experience. The default, and recommended, is binary mode, but you're given a choice on install. It affects C programs that specify "t" to fopen() and friends, and causes Cygwin to convert line endings to and from DOS. But it's more trouble than it's worth.

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

#30

Post by Graphon »

projectileboy wrote: post #11

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/

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.

Post reply on HN