Re: two problems with cygwin's zip

["Fred T. Hamster" <fred at gruntose dot com>]

cgf wrote:
    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 responded.

the drive letter must be included in the path; that's when i see the problem in the resulting zip file.  perhaps the main issue is not detecting the letter & colon combination at the start of the path.

cgf wrote:
    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
    cygwin.

<pique>
  if i've missed the point, then you should be glad cygwin has such confused folks as myself tagging along behind the pack, since i have been using the cygwin tools successfully for several years now to run my bash & perl scripts, to manage a build environment at work, to keep track of my source code at home, etc.  i hope all the people having trouble with that concept are as successful as myself in using cygwin.
</pique>
  ego wrestling aside, i think that the important point this has raised for me is whether cygwin is in reality an open system or a closed system.  signs are pointing me towards thinking that it's kind of closed.  here's why, in part:
    1) if it really is not a goal to properly handle native filename paths within cygwin, then this severely limits its appeal for those already familiar with cygwin's single target platform (win32).  in my opinion, one cannot simultaneously disdain the win32 path conventions and yet also promote a product that is intended exclusively for win32 without resorting to some form of schizophrenia.
    2) i noticed a while ago that the only processes shown in 'ps' are cygwin applications, or users of the cygwin library.  this struck me as odd at the time, and a little frustrating since i had been planning to re-use some of the cygwin code in an open source project for process management (and it needed to interact with arbitrary other processes in the system, not just cygwin-based apps).  this behavior is however consistent with cygwin really being intended as a closed system, i.e. exclusively an emulation environment for unix applications that cannot interact with other processes in the win32 environment outside the cell wall.
  however, i didn't find this "closed" aspect of cygwin clearly stated in the FAQ.  perhaps that's the reason for my confusion and why i was expecting too much in its path handling capabilities.
  i am saddened if that is the true state of affairs however.  it seems like the tools could be a lot more effective if the OS-in-a-bottle aspect was dropped.  after all, cygwin is using the win32 file system to act on files.  it is using the win32 memory manager to allocate its data.  it's not that big of a leap to think that parsing the native paths might be supported too, especially given the language from the FAQ that "it is possible to write Win32 console or GUI applications that make use of the standard Microsoft Win32 API...".  to the best of my knowledge, the "standard microsoft win32 api" does in fact allow for backslashes in path names.
  that being said, i still feel cygwin is great and almost essential to life.  i wish i did have the time right now to look into these issues, but that will have to wait until later in the summer.  would such a patch (for glob, and possibly zip) actually be accepted into the codebase?
thanks,
fred.

-- 
_____ chosen by the Nechung Oracle Program [ http://www.gruntose.com/ ] _____

Believe those who are seeking the truth; doubt those who find it.
  -- Andre Gide

_____________ not necessarily my opinions, not necessarily not. _____________




--
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/