|
Interesting.... I have one Win8 machine and recently upgraded to 8.1 but haven't yet used VirtualBox on it. I have had issues with installing VirtualBox on a machine which had VPN client software that setup a virtual adapter. The VirtualBox installer would just hang due to that adapter. Scary that virtual box would screw up the drive contents!
So a clean re-install got cygwin working again?
|
|
|
|
|
Still fails. I have no clue what is going on, and I will try redownloading the installer tomorrow. My internet connection is kinda flaky at night.
Keep Clam And Proofread
--
√(-1) 23 ∑ π...
And it was delicious.
|
|
|
|
|
You're supposed to always use the most recent installer anyway. Although your symptoms are really suspicious, I've never seen anything like this.
|
|
|
|
|
I used to love cygwin, I still have it installed but these days I tend to use linux in a vm instead. How on earth do you deal with a 4gb text log file without less, tail and grep?
I had no idea there was a 64bit version though.
|
|
|
|
|
Last time I had a look at it, the 32bit version was pretty broken but at least semi-usable. The 64bit version was completely borken, seemingly beyond repair, but I guess it's been fixed now..
|
|
|
|
|
What are you all talking about? Cygwin is rock-stable. Any time it goes wrong, a simple rebase fixes everything (and it's not Cygwin's fault, it's a sh*tty windows DLL model).
|
|
|
|
|
vl2 wrote: a simple rebase fixes everything
If something requires fixing, that means it's broken.
It's also entirely its own fault - plenty of software works just fine on Windows without periodically using the excuse "yes but DLL model".
vl2 wrote: Cygwin is rock-stable.
Ok. Like I said, I haven't used it in a while. Maybe it got better.
|
|
|
|
|
DLL offsets are broken by Windows and the other windows software. And windows does not support position-independent DLLs (in 21st century! omg!), so the usual Unix model does not map well onto windows practice.
I've been using cygwin since around 1999, and it was pretty solid back then. The only real problem with cygwin (back then, and still affecting) is load times for heavy C++ applications, due to a lack of lazy static initialisation (again, thanks to an outdated and crappy COFF model).
|
|
|
|
|
vl2 wrote: I've been using cygwin since around 1999, and it was pretty solid back then.
Really? Never even a "nope, there's a space in that path so I'm just going to completely freak out"?
The first (and only) time I tried the 64bit version, it just completely refused to work at all. Some arcane error when trying to start that shell thing.
|
|
|
|
|
Unix tools will freak out on spaces in paths anyway, no matter what your underlying platform is. It's not a bug, it's a feature.
But I admit I never tried cygwin on Windows8, and I'm not going to leave 7 any time soon.
|
|
|
|
|
Most paths on Windows have spaces. Refusing to deal with that reality is absolutely not a feature.
|
|
|
|
|
Cygwin feature is to be POSIX-compatible. Introducing incompatibilities for a sake of some stupid spaces is not an option.
|
|
|
|
|
Great, so it's stuck between not working and not working.
|
|
|
|
|
It is working, perfectly. Just not the way windows-minded folk expects it to.
|
|
|
|
|
Ok, try to install it in a directory with a space somewhere in it then. Like "Program Files". That's supposed to work, right? Well it didn't.
That it doesn't like paths with spaces in it internally in its own little world is fine. That's not what I'm talking about.
|
|
|
|
|
Why is it "supposed to work", to start with? Windows mindset is such an amusing, funny little thing!
|
|
|
|
|
When in Rome .. well you know the saying.
Having a limitation "installation directory may not contain spaces" is a bug. There are simply no excuses. Paths contains spaces on Windows. Almost always. That limitation essentially means it can't be installed at all, except in some places that are off-limits like "C:\".
How would you like it if people "ported" things from windows to linux and kept all the windows-quirks?
|
|
|
|
|
vl2 wrote: Why is it "supposed to work", to start with?
You do in fact understand what OS Cygwin runs on right?
You also understand that even when Cygwin was introduced the concept of dual booting already existed so if someone did in fact want to run Linux/unix then they had that option already. Thus the point of Cygwin is to add to the windows environment,not replace it - and you also understand that?
|
|
|
|
|
Point of Cygwin is to make Windows at least a little bit usable, because without the normal scripting tools it was just a shell for running Word (which is itself pretty useless too). Removing spaces from the "standard" paths is a tiny price for such a huge value.
|
|
|
|
|
vl2 wrote: Point of Cygwin is to make Windows at least a little bit usable
Nonsense.
vl2 wrote: because without the normal scripting tools it was just a shell for running Word
Not sure what you are referring to but I was running scripts in windows before cygwin existed.
|
|
|
|
|
You just confessed that you do not understand scripting at all. How were you "running scripts" then?
|
|
|
|
|
vl2 wrote: You just confessed that you do not understand scripting at all
The fact that you can't read doesn't mean that your fantasy life is now reality.
|
|
|
|
|
vl2 wrote: Just not the way windows-minded folk expects it to.
That is similar to claiming that OSX works on Macs but because it doesn't work on a windows machine that the windows machine is broken.
And presumably you would also claim that Linux is broken since it provides methods that allow spaces in paths as well.
|
|
|
|
|
You're free to use spaces in paths, of course. Just never expect any scripts with string escaping work with them. No matter what your OS is. Something is terribly broken in the heads of those who allows spaces in the paths - they're making it nearly impossible to deal with their infrastructure with any scripting environment. COMMAND.COM chokes on spaces too, by the way.
|
|
|
|
|
vl2 wrote: COMMAND.COM chokes on spaces too, by the way.
Command.com?
Perhaps you were referring to cmd.exe. I use spaces in paths in the batch scripts that I write for windows and nothing "chokes" so other than that I have no idea what you are referring to.
vl2 wrote: they're making it nearly impossible to deal with their infrastructure with any
scripting environment.
Actually rather trivial in my experience. At least once one is aware of it and handles it properly. Much harder for example, in my experience, to track down different types of syntax for different script languages.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
