Re: two problems with cygwin's zip

["Robert Collins" <robert dot collins at itdomain dot com dot au>]

----- Original Message -----
From: "Fred T. Hamster" <fred@gruntose.com>


> cgf wrote:
>     I don't see this.  If I type:
>
>     zip /tmp/foo /bin/ls
>
>     "bin/ls" is added to the archive.  I actually tried this before I
responded.
>
> the drive letter must be included in the path; that's when i see the
problem in the resulting zip file.  perhaps the main issue is not
detecting the letter & colon combination at the start of the path.

Perhaps you missed what cgf wrote? "zip" does not understand drive
letters and colons. If zip simply passes the path onto cygwin1.dll the
behaviour will be ok, but if zip parses the path at all, you will likely
have problems.

<SNIP>
>   ego wrestling aside, i think that the important point this has
raised for me is whether cygwin is in reality an open system or a closed
system.  signs are pointing me towards thinking that it's kind of
closed.  here's why, in part:
>     1) if it really is not a goal to properly handle native filename
paths within cygwin, then this severely limits its appeal for those
already familiar with cygwin's single target platform (win32).  in my
opinion, one cannot simultaneously disdain the win32 path conventions
and yet also promote a product that is intended exclusively for win32
without resorting to some form of schizophrenia.

The goal is to allow programs that use "/" to run on an OS that uses "\"
and ":" and ".". I didn't read Chris's email as disdaining the
conventions - he just pointed out that cygwin is all about applications
from unix being able to remain ignorant, and yet still function properly
within the platform.

cygpath is provided to allow scripts to call cygwin/non cygwin programs
(ie
$ zip ./foo.zip `cygpath -u c:\cygwin\bin\ls.exe`)
And the cygwin1.dll allows full access to all win32 files via the
/cygdrive/x/ mechanism.

>     2) i noticed a while ago that the only processes shown in 'ps' are
cygwin applications, or users of the cygwin library.  this struck me as
odd at the time, and a little frustrating since i had been planning to
re-use some of the cygwin code in an open source project for process
management (and it needed to interact with arbitrary other processes in
the system, not just cygwin-based apps).  this behavior is however
consistent with cygwin really being intended as a closed system, i.e.
exclusively an emulation environment for unix applications that cannot
interact with other processes in the win32 environment outside the cell
wall.

Have you tried
$ ps -W
? That certainly shows all the win32 process's. I'm not sure how you are
concluding that cygwin1.dll has a 'cell wall' when you haven't actually
looked at what cygwin1.dll is capable of!

>   however, i didn't find this "closed" aspect of cygwin clearly stated
in the FAQ.  perhaps that's the reason for my confusion and why i was
expecting too much in its path handling capabilities.

It's not closed IMO. Any cygwin compiled program has full access to the
win32 API (with some minor caveats such as atfork() isn't aware of
native win32 created threads). Likewise any cygwin program is fully
accessible from win32.

<SNIP>
>   that being said, i still feel cygwin is great and almost essential
to life.  i wish i did have the time right now to look into these
issues, but that will have to wait until later in the summer.  would
such a patch (for glob, and possibly zip) actually be accepted into the
codebase?

Chris has already said that patches will be examined, and that he may be
wrong. Noone is going to guarantee that a patch that hasn't even been
written will be accepted. Chris will probably give such patches a fair
hearing however - I've not seen him do otherwise.

Rob


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