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

[Charles Wilson <cwilson at ece dot gatech dot edu>]

"Fred T. Hamster" wrote:
>         All tools may be used from the Microsoft command line prompt,
> with full support for normal Windows pathnames.
> 
> that text would seem to indicate fairly strongly that cygwin is actually
> intended to support "normal windows pathnames" after all.  a big issue
> for me at least is that cygwin does not in fact support "normal windows
> pathnames" currently.  

What is "cygwin"?  That seems to be the core problem here.  cygwin, the
dll, understands and supports normal windows pathnames.  zip, the tool
that happens to run under cygwin, does not.  bash, the tool that happens
to run under cygwin, does (in certain circumstances).

So, does "cygwin" support normal windows pathnames?

Maybe.  Yes.  No.  I dunno -- depends on your definition of "cygwin".

So, *why* does zip not support normal windows pathnames?  Well, zip was
"ported" *just enough* that it would compile successfully and work under
cygwin -- when called the same way you would call it under unix.  That
is, with '/' dirseps and no drive: roots.  (Note that the concept of a
multi-rooted directory structure -- a:, b:, c: etc -- is completely
foreign to most unix utilities that expect a single-root  dirtree).

Since zip must do directory manipulation itself (is this argument an
absolute-rooted pathname: yes, strip leading '/'. How many files in the
specified directory?  Should I recurse? etc) it doesn't rely on
cygwin1.dll's internal pathname stuff.  Should it?

Maybe.  But probably not -- because zip MUST manipulate the pathnames --
you want it to strip the leading A:/ (cygwin1.dll won't do that;
root-stripping behavior is not general purpose. Root-stripping is unique
to archival tools)

There are *native* ports of zip that handle root-stripping with "normal
(braindead) windows pathnames".  Why do extra work (hours of effort)
when, for an additional 50k of disc space the user can download and
store "doszip" and use that for "normal windows pathnames".  There's no
benefit -- and great possibility of harm, since these changes can screw
up the "normal UNIX pathname" handling in cygwin-zip.

Is "a:fred" a filename with six characters (on unix, yes), or a
four-character filename in the current directory under the a: root
(remember, windows/dos keeps multiple "current directories" -- one for
each root)  And let's not even get started on the multiple streams
allowed when using NTFS -- "a:fred" can be "fred" on the a: drive, but
can also mean the file "a" in the current directory, but accessing the
stream named "fred" within the file "a".

> is that statement of support above just marketing
> lingo, or is it a real commitment?  i sincerely hope that it's real.

Again, depends on what you define as "cygwin".  *I* don't do marketing,
or hype.  *I* provide and maintain the zip package, and *my* performance
(or lack thereof) has NOTHING to do with Red Hat, RH's marketing
department, their web page, or even the cygwin project's webpage and
statements.

I provided the damn thing because it was useful, required some effort on
my part to port, compile, and package, and I wanted others to be able to
use it rather than hoard it to myself.  However, no good deed ever goes
unpunished.

Now, YOU come along and complain that it isn't good enough, but you're
not going to dig in the the source code and provide a patch.  And then
accuse me (or the good folks at Red Hat) of "marketing hype".  Well, I'm
sorry, I'm a volunteer, for God's sake.  I'm not paid by RH; anything I
do w.r.t. cygwin is directly time away from my dissertation.  Also, *I*
didn't say anything about whether cygwin's "zip" supports the braindead
filesystem of "native" windows.

Apparently, it doesn't.  News to me -- I built it for use under
bash/cygwin, and never even *tried* to run it from cmd.exe (I despise
cmd.exe only slightly less than I abhor command.com).  If you send me
patches to enable your desired functionality in zip, I will consider
them, as long as there is NO detrimental impact to zip's behavior under
bash or when used with "normal" unix pathnames.  But I'm not going to
waste my time developing functionality that is redundant, when there are
several already-extant ways to get your desired behavior:

cygpath -u
a "native" port of zip
/cygdrive/a/

--Chuck

--
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/