two problems with cygwin's zip

Robinow, David
Tue Jun 26 10:22:00 GMT 2001

> From: Fred T. Hamster [ ]
> Subject: 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...
 This is the way 'zip' works. It is not a bug and it has nothing to do with
cygwin.  Take it up with the 'zip' authors.
 Actually I think 'zip' could use a few more options for path handling but
the cygwin list is not the place to address this.
>   it seems pretty disturbing to me that a unix emulation environment 
> running under ms-windows would have many problems parsing 
> ms-dos paths.
 It would disturb me a lot more if programs broke because somebody insists
on confusing windows with unix.
>  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.
 Why are you using cygwin zip?  The native zip.exe should handle this
>   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.
> thanks,
> fred.

Unsubscribe info:
Bug reporting:

More information about the Cygwin mailing list