Prev: Makefile picked by make
Next: EFBIG and determination of max file, et al.
From: David Given on 12 May 2010 18:46
On 12/05/10 02:11, Kenny McCormack wrote:
[...]
>> The main reason I chose Interix over Cygwin --- apart from the usual one
>> of Cygwin being an abomination from the uttermost depths of hell --- is
>
> Just curious: Why do you hate Cygwin so?

I have to use it at work.

We spend a *stupid* amount of time working around issues involving
Cygwin. As a short list, this is all stuff I've ran into recently:

- creating a file called 'aux.c' failed until quite recently (as 'aux'
is a reserved filename in Windows. They've fixed this, thank god)

- you cannot unlink a file if another process has it open (a win32
limitation)

- you cannot run applications from more than one version of Cygwin at a
time (I once had to deal with a customer machine with *three* different
versions of Cygwin on it at once. That wasn't fun. I believe this has
also been fixed recently, although not recently enough to help us)

- Cygwin applications automatically parse their argument string into an
argv array if they think they've been invoked from a cmd.exe session
(this doesn't happen automatically on Windows), and the heuristic is
easily confused... resulting in command line quotes mysteriously
vanishing under some circumstances

- strong runtime requirements, where just running a Cygwin .exe from a
cmd.exe session won't always work unless you set up environment
variables etc, meaning that Cygwin apps won't play nicely with
non-Cygwin build tools without jumping through hoops

- an infamously terrible installer which will frequently mangle your
Cygwin installation beyond repair, and where due to a UI glitch it's
sometimes impossible to uninstall two packages because every time you
select one it will mark the other one for reinstallation

- most of the packages are rather old and the selection is poor (no
libzip? Really?)

- NO MAN PAGES

- Cygwin has a VFS which tries to enforce Unix-like paths, such as
/cygwin/c/foo/bar/baz instead of the Windows-like c:/foo/bar/baz;
unfortunately none of the third-party tools that we're trying to script
understand Cygwin paths, resulting in huge piles of cumbersome
translation layers in all our scripts

Basically what they've done is applied huge amounts of work and clever
hackery to produce an almost convincing Unix-alike that runs on Windows.
It remains almost convincing until you try to interact with tools
outside Cygwin, at which point all the hacks suddenly become visible,
and instead of helping you, they get in the way. The whole reason for
running Cygwin is so that we can interoperate with third-party tools and
compilers; after all, if we wanted a real Unix-alike, we'd run on a real
Unix! So when we come across issues like Cygwin's make not understanding
compiler-generated dependency files containing c:/foo paths because they
haven't applied the standard patch to make it do so, we get
understandably irritated.

There's actually another project called MingW that does much the same
thing Cygwin does, except their policy is not to emulate features that
Windows does not support. As a result their system is much less
Unix-like... but it's much more consistent and as such is perversely
easier to use.

[...]
> I wonder why they do it that way at all. Many authors have noted that
> the whole Unix way of doing process creation - the idea of creating two
> identical processes when such is wasted in 99% of cases - is a quirk.

This is a perfect example; Cygwin is emulating fork() because they want
to be as Unix-like as possible. MingW does not implement fork() at all
because it can't be done easily on win32, but I believe they do
implement vfork() --- because that *can* be done.

--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│
│ "There is no Fermi Paradox. Any time space faring aliens make it to
│ Earth, the cows get them." --- Sam Starfall
From: Ersek, Laszlo on 12 May 2010 20:30
On Wed, 12 May 2010, David Given wrote:

> [...] The whole reason for running Cygwin is so that we can interoperate
> with third-party tools and compilers; after all, if we wanted a real
> Unix-alike, we'd run on a real Unix! [...]

So that a different opinion is voiced too: I have different needs and also
different possibilities at work, and for me Cygwin is a lifesaver. In
order to Get Things Done (TM), I need a rootless X server, about five
xterms, bash prompts, GNU coreutils, OpenSSH, a platform where my own
utilities build and run, and so on. I vaguely remember having experimented
with other, similar tool compilations, but for interactive use, Cygwin
seemed the most polished.

http://cygwin.com/faq.html

----v----
1.1. What is it?

The Cygwin tools are ports of the popular GNU development tools for
Microsoft Windows. They run thanks to the Cygwin library which provides
the POSIX system calls and environment these programs expect.

With these tools installed, it is possible to write Windows console or GUI
applications that make use of significant parts of the POSIX API. As a
result, it is possible to easily port many Unix programs without the need
for extensive changes to the source code. This includes configuring and
building most of the available GNU software (including the packages
included with the Cygwin development tools themselves) as well as lots of
BSD tools and packages (including OpenSSH). Even if the development tools
are of little to no use to you, you may have interest in the many standard
POSIX utilities provided with the package. They can be used from one of
the provided Unix shells like bash, tcsh or zsh, as well as from the
standard Windows command shell if you have to for some sad reason.
----^----

Cheers,
lacos
From: David Given on 13 May 2010 16:01
On 13/05/10 01:30, Ersek, Laszlo wrote:
[...]
> So that a different opinion is voiced too: I have different needs and
> also different possibilities at work, and for me Cygwin is a lifesaver.
> In order to Get Things Done (TM), I need a rootless X server, about five
> xterms, bash prompts, GNU coreutils, OpenSSH, a platform where my own
> utilities build and run, and so on.

This sounds like you're largely staying inside the Cygwin box, and it
*does* work well in that situation, as I should have made clearer (it's
a very impressive piece of work and I couldn't achieve anything like
it). I find that it's only when you start to stray outside the box and
need to interact with non-Cygwin tools that it starts to fall apart.
Unfortunately for us, this is largely what we need it for.

Just out of interest, given that your tools are so Unix-based, what are
the reasons for using Windows? Third-party tools? Corporate IT?

--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│
│ "There is no Fermi Paradox. Any time space faring aliens make it to
│ Earth, the cows get them." --- Sam Starfall
From: Ersek, Laszlo on 13 May 2010 19:22
On Thu, 13 May 2010, David Given wrote:

> This sounds like you're largely staying inside the Cygwin box

That's right.

[...]

> Just out of interest, given that your tools are so Unix-based, what are
> the reasons for using Windows? Third-party tools? Corporate IT?

Both of those. With the addition of Cygwin, my work environment became
bearable, sometimes even pleasant. Ten years ago I would have started a
crusade for a pure GNU/Linux workstation. Now I'm too old for that :)

Cheers,
lacos
From: Kenny McCormack on 15 May 2010 11:34
In article <1nnrb7-2og.ln1(a)gate.cowlark.com>,
David Given <dg(a)cowlark.com> wrote:
>On 12/05/10 02:11, Kenny McCormack wrote:
>[...]
>>> The main reason I chose Interix over Cygwin --- apart from the usual one
>>> of Cygwin being an abomination from the uttermost depths of hell --- is
>>
>> Just curious: Why do you hate Cygwin so?
>
>I have to use it at work.
>
>We spend a *stupid* amount of time working around issues involving
>Cygwin. As a short list, this is all stuff I've ran into recently:

See my comments below. Understand that I've never seen the point in
using Cygwin as a user environment; I totally agree with what you say
that if you wanted to run Unix, you'd install and run Unix. However
note that, from various Usenet posting over the years, I get the idea
that some people use Cygwin to get work done in an environment where
management prevents them from installing Linux (or even saying the word)
- i.e., they sort of run Cygwin on the sly as a way to get around
corporate policies.

That said, I've only used it to compile Unix-y tools into binaries (EXE
files) that can be run by other people, from the CMD prompt. I note
that another poster on this thread was going on about all the tools that
Cygwin provides - again, I disagree with that POV; If you want
Unix/Linux, you know where to find it (unless you are doing it, as noted
above, as an end-around of your corporate IS policies).

Final note: My text below could be interpreted to sound like the typical
smarmy Usenet response - that is, the usual tone of "Hey, I'm fine;
you're just dense". Trust me; it is not intended as such. I really do
understand your points. What I've tried to make clear is that if you
treat Cygwin as just a compilation system, then you should be OK.
People get in trouble when they start expecting to use it as an
"environment".

>- creating a file called 'aux.c' failed until quite recently (as 'aux'
>is a reserved filename in Windows. They've fixed this, thank god)

Yeah, that's an old chestnut. I wonder if Bill Gates turns over in his
sleep over that decision (making ordinary words act like device names),
made so very long ago. Incidentally, note that DOS had an
(undocumented) option that, if enabled, turned off the "automatic"
recognition of things like "AUX" ("CON", "PRN", etc); that is, required
them to be prefixed with "\dev\" (or "/dev/", if you prefer), like in
Unix. I don't think that option survived into the present day.

>- you cannot unlink a file if another process has it open (a win32
>limitation)

Yeah, that's Windows. I should point out that many (most?) of your
complaints are really just "That's Windows!". I.e., you just can't do
anything about it - since, underneath it all, you're still running Windows.

>- you cannot run applications from more than one version of Cygwin at a
>time (I once had to deal with a customer machine with *three* different
>versions of Cygwin on it at once. That wasn't fun. I believe this has
>also been fixed recently, although not recently enough to help us)

Yeah, that's a pain. I assume you are talking about the underlying
cygwin1.dll. Yes, every time I have to install a new version of
cygwin1.dll, I worry about what breakage is going to result. So far,
I've been pretty lucky.

>- Cygwin applications automatically parse their argument string into an
>argv array if they think they've been invoked from a cmd.exe session
>(this doesn't happen automatically on Windows), and the heuristic is
>easily confused... resulting in command line quotes mysteriously
>vanishing under some circumstances

I'm not quite sure what you are getting at here. Are you just saying
that the command line parsing is different between Cygwin apps and
"normal" DOS/Windows apps? If so, I don't what could be done. That, in
fact, was always a problem in the DOS/Windows world - that since the
shell doesn't do the command line parsing, each app has to do it, and
each app does (read: could/potentially, do) it differently.

>- strong runtime requirements, where just running a Cygwin .exe from a
>cmd.exe session won't always work unless you set up environment
>variables etc, meaning that Cygwin apps won't play nicely with
>non-Cygwin build tools without jumping through hoops

I don't get this. Yes, you have to setup environment variables for
things to work right. That's part of the game.

>- an infamously terrible installer which will frequently mangle your
>Cygwin installation beyond repair, and where due to a UI glitch it's
>sometimes impossible to uninstall two packages because every time you
>select one it will mark the other one for reinstallation

I haven't seen this, but I'll take your word for it.

>- most of the packages are rather old and the selection is poor (no
>libzip? Really?)

Can't you compile it yourself?

>- NO MAN PAGES

I just did "man ls" on my Cygwin installation. Worked fine for me.

>- Cygwin has a VFS which tries to enforce Unix-like paths, such as
>/cygwin/c/foo/bar/baz instead of the Windows-like c:/foo/bar/baz;
>unfortunately none of the third-party tools that we're trying to script
>understand Cygwin paths, resulting in huge piles of cumbersome
>translation layers in all our scripts

Yes, that's annoying, but easily worked around (at least in the current
version). I recently installed Cygwin on a machine, and when I ran an
app, passing it something like "C:/foo", a paragraph long message came
out that told me that it prefers POSIX style file names, but that if you
set the CYGWIN environment variable to "nodosfilewarning", it will shut
up about it. I did, and it did.

>Basically what they've done is applied huge amounts of work and clever
>hackery to produce an almost convincing Unix-alike that runs on Windows.
>It remains almost convincing until you try to interact with tools
>outside Cygwin, at which point all the hacks suddenly become visible,
>and instead of helping you, they get in the way. The whole reason for
>running Cygwin is so that we can interoperate with third-party tools and
>compilers; after all, if we wanted a real Unix-alike, we'd run on a real
>Unix! So when we come across issues like Cygwin's make not understanding
>compiler-generated dependency files containing c:/foo paths because they
>haven't applied the standard patch to make it do so, we get
>understandably irritated.

True. So it goes...

>There's actually another project called MingW that does much the same
>thing Cygwin does, except their policy is not to emulate features that
>Windows does not support. As a result their system is much less
>Unix-like... but it's much more consistent and as such is perversely
>easier to use.

Yes. But I've had less than good results with MingW.
I've posted recently - actually, in comp.lang.awk - about my recent
experiences with it.

>[...]
>> I wonder why they do it that way at all. Many authors have noted that
>> the whole Unix way of doing process creation - the idea of creating two
>> identical processes when such is wasted in 99% of cases - is a quirk.
>
>This is a perfect example; Cygwin is emulating fork() because they want
>to be as Unix-like as possible. MingW does not implement fork() at all
>because it can't be done easily on win32, but I believe they do
>implement vfork() --- because that *can* be done.

Indeed.

--
> No, I haven't, that's why I'm asking questions. If you won't help me,
> why don't you just go find your lost manhood elsewhere.

CLC in a nutshell.

First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Makefile picked by make
Next: EFBIG and determination of max file, et al.