two problems with cygwin's zip
Tue Jun 26 10:22:00 GMT 2001
> From: Fred T. Hamster [ mailto:firstname.lastname@example.org ]
> 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.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
More information about the Cygwin