Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sources DOT redhat DOT com
Message-ID: <80575AFA5F0DD31197CE00805F650D7602CF4D@wilber.adroit.com>
From: "Robinow, David" <drobinow AT dayton DOT adroit DOT com>
To: cygwin AT cygwin DOT com
Subject: RE: two problems with cygwin's zip
Date: Tue, 26 Jun 2001 12:16:20 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"

> From: Fred T. Hamster [mailto:fred AT gruntose DOT com]
> 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
properly.
>   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:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/