This is the mail archive of the
mailing list for the Cygwin project.
Re: two problems with cygwin's zip
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...
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.
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. it's probably also a reasonable
assumption that backslashes are escape characters only when they are
escaping something that needs it, such as a space embedded in a
pathname. unfortunately, that leads to consideration of the pattern
"\*", which might be an escaped asterisk or which might be a wildcard
appended to an ms-dos path. again, if that asterisk was seen in an
absolute dos style path (e.g., f:\blah\* ), then it's almost certainly a
wildcard. and if one is willing to ignore the yelping of people who
routinely put asterisks in their filenames, then asterisk could always
be assumed to be a wildcard.
i was under the impression that the path processing was central to the
cygwin dll, perhaps in the glob() function. i doubt zip is implementing
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.
ps: i can live with issue 2 being ignored, but issue 1 (see below re
absolute paths) impacts me almost every day. my current workaround
requires changing to the drive where the files live and using a relative
path. that definitely seems like a kludgey approach which shouldn't be
necessary, but which currently is required. if there is no maintainer
for the zip tools, then i will go ahead and attempt this fix myself
someday. but i'd rather pass it along to the person with the deeper
knowledge of the code.
_____ chosen by the Nechung Oracle Program [ http://www.gruntose.com/ ] _____
The credit belongs to those who are actually in the arena, who strive
valiantly; who know the great enthusiasms, the great devotions, and speed
themselves in a worthy cause; who at the best, know the triumph of high
achievement; and who, at the worst, if they fail, fail while daring
greatly, so that their place shall never be with those cold and timid
souls who know neither victory nor defeat.
-- Theodore Roosevelt
_____________ not necessarily my opinions, not necessarily not. _____________
Christopher Faylor wrote:
>On Tue, Jun 26, 2001 at 11:05:27AM -0400, Fred T. Hamster wrote:
>>i have checked the faq and the mailing list and don't find the totally
>>relevant answers, so here are the problems...
>>1) zip saves absolute paths in the zipfile. for example, if i zip up
>>"l:\source\lib_src\library\basis"/* into a zip file, all of the files in
>>the archive start with "l:\". this leads, on unzipping, for zip to want
>>to write them back into "l:\" rather than unzipping into the current
>>directory. that is clearly a bad choice if my files on l:\ are somewhat
>>better versions than those in the zip.
>> the infozip distribution doesn't exhibit this behavior in the dos
>>port; instead, it chops off the absolutist part of the path and leaves
>>it as "source\lib_src\library\basis".
>> note that using the -j flag to junk the paths is not appropriate; my
>>zip files often contain 50-100 directories. i definitely don't want
>>them to all be dropped into the same directory on unzipping.
>Cygwin is a UNIX emulation environment. The cygwin zip program is a
>UNIX port. It probably doesn't know that \ is equivalent to /.
>We don't guarantee that every port of every utility that is distributed
>with cygwin will properly handle MS-DOS path syntax. I don't think
>that many package maintainers even care about this.
>So, use forward slashes in your filenames. That is one of the whole
>reasons for Cygwin -- the ability to use UNIX paths.
>If you don't want to use Cygwin's UNIX path name facilities then you
>should just be using a native zip port.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html