Cygwin: Open or Closed System? (was: two problems with cygwin's zip)

[Christopher Faylor]

On Wed, Jun 27, 2001 at 11:11:19AM -0400, Fred T. Hamster wrote:
>Christopher Faylor wrote:
>> I'm glad that you could use cygwin without understanding the motivation
>> behind its existence.  I don't think that this should either be a
>> bragging point or an argument in favor of changing the way that we've
>> been doing things.
>
>i'm really sad that the tone of the cygwin mailing list seems to be
>"users come here to be beaten".  blunt tools arguments aside, i can't
>see the above as much beyond an insult.  insults don't prove points
>either.

How are you insulted?  Because I used the term "brag"?  Isn't that what
you were doing in your <pique></pique> paragraph?  Weren't you proudly
proclaiming that may have missed the point but that you were still using
cygwin successfully?  What am I supposed to take away from this:

>><pique>
>>if i've missed the point, then you should be glad cygwin has such
>>confused folks as myself tagging along behind the pack, since i have
>>been using the cygwin tools successfully for several years now to run
>>my bash & perl scripts, to manage a build environment at work, to keep
>>track of my source code at home, etc.  i hope all the people having
>>trouble with that concept are as successful as myself in using cygwin.
>></pique>

I'm sorry if I incorrectly mischaracterised this as bragging.  It seems
to have all of the earmarks but then it is always hard to tell in email.

My point was that the fact that you were not aware (due to crappy
documentation) that cygwin was designed expressly to provide a
UNIX-on-windows environment (primarily for GNU tools) cannot be used as
an argument to strengthen your position that we should refocus our
efforts on somehow improving MS-DOS path support.

However, if I offended you, I sincerely apologize.

>i for one cannot accept the rationale being promulgated that a system
>for unix emulation on win32 should be ignorant of the native platform's
>path specification, when calling into the environment from windows is
>clearly a desirable capability.  to me, that rationale seems to
>drastically underrate how useful better handling of wildcards in the
>presence of backslashes would be.

Who is saying any such thing?  Here again, you seem to have chosen
inflammatory words.  "the rationale being promulgated...win32 should be
ignorant".  Who has even implied any such thing?

I have said that I, personally, am not very interested in MS-DOS path
support.  Chuck has also implied limited interest.  The fact that we do
not want to spend time doing something that does not interest us is our
right.  It is your privilege to be able to supply patches to rectify
oversights that you see.  No one will stop you from doing that.  In
fact, I even said that I would applaud your efforts -- although you have
deleted that part of my email:

>>If you want to start a one man campaign for improving all of the tools
>>so that they work with MS-DOS paths, then I will applaud your efforts.

Hundreds of thousands of people are using the product in its present
state and, presumably, happily typing '/' rather than '\' and using the
mount system that was specifically and painstakingly set up to avoid the
MS-DOS path syntax.

Despite the fact that we have lavished incredible amounts of time on
perfecting cygwin's mount system, cygwin still understands MS-DOS
paths.  There is a not insubstantial amount of code in cygwin for
dealing with MS-DOS paths.

You've stumbled across the oft-discovered fact that Cygwin's glob
function does not deal well with colons and backslashes.  This now seems
to be the focus of your messages although it is unrelated to your
original "zip" problem -- I just checked the sources and as far as I can
tell, the word 'glob' does not show up anywhere.

Anyway, the solution to this problem is really really simple.  Provide a
patch to fix the behavior.

No one is arguing that increased awareness of MS-DOS paths is wrong.
The point I have been repeatedly been trying to make is that, given the
nature of the project (which is not clear from the documentation,
apparently), you should not *expect* that every tool works perfectly
with MS-DOS paths.

The reason for this is not 1) that the cygwin DLL is "ignorant" of MS-DOS
paths (with the exception of glob) or 2) that we all "disdain" MS-DOS paths.

The reason is simply that modifying packages like zip, cp, find, or bash
to understand MS-DOS paths is not a trivial task.  Under Cygwin, it
should be trivially easy to configure and build something like bash for
a UNIX environment.  It will then "just work" on Windows with the caveat
that bash will continue to expect UNIX paths as it does on UNIX.

And, that is great.  That *is* the whole reason for cygwin.  There are a
few things, missing in Windows, that the original designers of cygwin
set out to emulate: 1) fork, 2) exec, 3) UNIX paths.  A lot of time and
sweat was put into all of those issues.

Cygnus could have chosen an alternate route.  They could have chosen to
effectively port every single application to be fully Windows capable.
That would mean rather than spending time on one thing, cygwin, they
would have had to port, gcc, gdb, make, bash, bison, binutils, ld, gas,
diff, patch, etc.  The economy of developing cygwin, and making cygwin
use UNIX paths should be pretty obvious as should the difficulty in
porting 80+ applications to understand MS-DOS paths.

>i am beginning to see how my standpoint could be confused with a lack
>of understanding of the rationale behind cygwin...  i don't pretend to
>know the real motivation at work in the language above, but if a "hack
>and slash" style of response is a habitual refuge for questions
>potentially indicating fundamental issues, then the chance for real
>dialogue in the list is pretty well hindered.

You seem to be exaggerating my evil intent while remaining ignorant of
your own style.  You use words such as "marketing hype", "disdain", and
"pique".  You're "saddened by the state of affairs".  You find it "odd"
and "frustrating" that 'ps' doesn't do exactly what you wanted.

At whom were those hyperbolic comments directed?

>i apologize if i'm just making up that interpretation of your tone.
>but just because i don't agree with this aspect of cygwin does not in
>turn mean it's appropriate that abuse shall be heaped upon me.

Since you obviously took offense, I will apologize again.  If this
conversation is to continue, let's watch the hyperbole.

(I've just scoured this message for inflammatory adjectives.  I hope I
haven't missed any.)

>> I will grant you that the documentation is not clear.  Hopefully we'll fix 
>> that soon so that further people will not be confused.
>
>so the "expectations as a windows programmer" are going to be reduced
>such that there is no expectation of wildcard support?  this is quite a
>bummer to me.  but i guess it might help to reduce the expectations of
>people for what cygwin can do.

No.  I am not saying that.  I'm saying that I will review any patch
that you send.  If you can make glob understand MS-DOS paths, I'll
apply the patch.  Please check out the Contributing link on the cygwin
web page for details on how to contribute patches.

>>Until then, I've told you in several email messages how cygwin is
>>supposed to operate.  I have mentioned that it is not feasible to port
>>every single package to work with MS-DOS pathnames.  I really don't
>>know why you don't understand this.  Or, rather, I don't know what you
>>expect to happen.  Are you expecting that the volunteers who contribute
>>to the project will drop everything and work on zip?
>
>i don't see how you read those expectations into my comments.  and in
>previous emails, i have honed down the exact issue that i am talking
>about; perhaps that focus is appearing to you as a lack of
>understanding instead.  currently, my main interest is in seeing if
>there is a project wide improvement in interoperability possible by
>modifying glob().  i have made a sincere offer to look into this, but
>the language i hear (from the list at large) about the possible
>acceptance of that future patch wavers between "go for it" and "no
>bleating way".

Hmm. "No bleating way".  I don't recall even inferring that.  I guess you
aren't referring to me.

However, I was missing the point that you are now solely focused on glob.
I'm looking forward to your patch.

>>Or, if you are going to wait until later in the summer before you
>>actually look into anything, then that's fine.  Let's just stop arguing
>>about semantics.  I will trump you every time.  I can do that.  I'm a
>>closed system.
>
>semantics is meaning.  meaning is important.  i personally don't
>believe that might makes right...  in a truly collaborative project,
>there is no single voice that can shout all the others down.  i don't
>want to say that's what you're doing, although it did feel somewhat
>that way to me at times.  but this could easily be my misconstruing of
>the real spirit behind the words.

Ouch.  On rereading that sounded very high-handed of me.  I really
apologize for the tone, there, too.

What I was trying to say is that Cygwin's project direction comes from
me.  I understand where it has come from.  I know what it is intent is.

If you find words in the documentation that seem to suggest that it is
something other than what I have been struggling to explain, then the
documentation is wrong.  Scouring the source code and documentation for
phrases that support the fact that Cygwin must correctly handle MS-DOS
paths in every conceivable situation is a fruitless endeavor.  Much of
the documentation was written by people who were not aware of the history.
It is very conceivable that there are words in the documentation that
are just plain wrong.

So, I will freely admit that the documentation is not perfect and,
therefore, you could easily have come to some false assumptions about
the project's direction.  I do not grant that since the documentation is
wrong, we must reorient ourselves to match it.

If there is an outpouring of support for the fact that all cygwin tools
should handle MS-DOS paths, I'll be happy to add strong words to the
documentation.  I'll review patches.  I will not spend much more time
beyond that in doing new development to match popular opinion.  I hope
that this doesn't seem high handed.  I hope that no one thinks that I
(or Chuck, or whomever) should be working on things that don't interest
us because the community voted that it would be a good idea.

>i'm satisfied for now that the polarization against win32 wildcards is
>such that only a patch which can be analyzed would even have a chance
>of changing any opinions.  expect that the issue may re-arise and
>include some code for consideration in a month or two.

I'm sorry that that statement caused you to feel that way.  It was
a very poor choice of language on my part.

I was just trying to stop a discussion that I thought was going nowhere.
You are free to keep discussing this.  It is certainly on topic for
Cygwin.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/