Cygwin
-
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.
-
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 shitty 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.
-
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).
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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?
-
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.
-
Why is it "supposed to work", to start with? Windows mindset is such an amusing, funny little thing!
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?
-
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:
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.
-
vl2 wrote:
Pass a path from one .bat script to anothe
I bet I would be lost in complexity in no time so paths have nothing to do with it. Script languages for OS shells are quick convenience only. For complex solutions I write applications in real languages.