two problems with cygwin's zip
Tue Jun 26 10:51:00 GMT 2001
Actually, I get different behavior from zip than you do. Maybe my
configuration is wrong?
$ /usr/bin/zip ./asdf.zip /bin/ls
zip warning: No such file or directory
zip warning: could not open for reading: bin/ls
$ /usr/bin/zip ./asdf.zip /bin/ls.exe
adding: bin/ls.exe (deflated 53%)
My cygwin1.dll is not handling the .exe extension the same way it is on your
machine. I'm guessing that this has to do with the recent changes you've
been making to cygwin1.dll for .exe extension handling (my cygwin version is
from last Sunday 6/24/01).
> -----Original Message-----
> From: Christopher Faylor [ mailto:firstname.lastname@example.org ]
> Sent: Tuesday, June 26, 2001 12:32 PM
> To: email@example.com
> Subject: Re: two problems with cygwin's zip
> On Tue, Jun 26, 2001 at 12:03:56PM -0400, Fred T. Hamster wrote:
> >the first problem (of seeing absolute paths in zips) occurs
> when using
> >forward slashes as well. it's an absolute path issue rather than a
> >slash-handedness issue. thus, this is still a bug relevant
> to cygwin's
> >zip, even if we must discount slash issues in paths. but i don't
> >suggest that we abandon those issues...
> 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
> >it seems pretty disturbing to me that a unix emulation environment
> >running under ms-windows would have many problems parsing
> ms-dos paths.
> >i realize the intrinsic difficulties with the backslash as an escape
> >character, but i also am aware that many of the tools i use at the
> >office are really psyched about generating the backslash as the path
> >separator. if the cygwin tools are unable to handle those generated
> >paths, then that signficantly detracts from my ability to work with
> >cygwin on the ms-windows platforms.
> Again, I think that you've missed the point of the cygwin environment.
> Red Hat has almost zero interest in modifying UNIX tools to deal with
> the MS-DOS path syntax. That was one of the main points in developing
> I assume that package maintainers also have very little interest.
> So, while this may be vitally important to you, it is pretty much a
> non-goal for the project in general. That doesn't mean that we won't
> accept patches to make things work better with MS-DOS syntax but it
> probably does mean that no package maintainer is going to be
> in doing the work themselves.
> >in most paths it's fairly obvious which interpretation is intended.
> >backslashes after colons should probably always be considered
> >separators for the rest of the path.
> Of course there are well-know rules for interpreting MS-DOS
> paths. The
> path translation code in the cygwin DLL understands them in
> most cases.
> That doesn't mean that each of the 80+ packages in the Cygwin release
> understands them. If the code in zip, or cp, or vim assumes
> that paths
> contain '/' and know nothing about the "specialness" of a colon or a
> backslash, then there isn't anything that the Cygwin DLL can do. That
> application would have to be specially ported to understand MS-DOS
> >i was under the impression that the path processing was
> central to the
> >cygwin dll, perhaps in the glob() function.
> Cygwin's glob function comes straight from UNIX. I don't know if zip
> uses it. I doubt that it has any bearing on the matter of stripping
> absolute paths. glob doesn't do that. That is something
> that a program
> like zip would do for itself.
> >its own file globbing, so it seems that some additional code
> in the main
> >glob() function for these issues that are peculiar to ms
> platforms would
> >go pretty far in allowing cygwin to speak both flavors of
> slash. these
> >impressions are garnered from general unix experience rather than
> >specific knowledge of the cygwin implementation though.
> If you are really that interested in this, then you should definitely
> look at the source and educate yourself in what is going on. Perhaps,
> I'm wrong. Maybe zip is somehow using glob or some other function in
> some way that would be easily solved by modifying the cygwin DLL. For
> me, this is working as designed, so I'm not going to be
> trying to "fix"
> this and I sincerely doubt that the maintainer will be interested
> 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/
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
More information about the Cygwin