This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: two problems with cygwin's zip


On Tue, Jun 26, 2001 at 05:46:00PM -0400, Fred T. Hamster wrote:
>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.

Huh?  If you're including the drive letter then this is not a UNIX 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>

I can easily imagine a person who has no mechanical knowledge operating
a car.  The fact that they operate a car does not make them racing
superstars.

I'm glad that you could use cygwin without understanding the motivation
behind its existence.  I don't think that this should either be a
bragging point or an argument in favor of changing the way that we've
been doing things.

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

Who said anything about disdaining?  I said that I had no interest.
If you have interest provide a patch.  Are you expecting me to do
something that I have no interest in doing?

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

Others have pointed out the existence of the -W option, however, you are
not wrong.  Cygwin is designed to be a UNIX-like system.  It has reported
on only cygwin process for a very long time.

One reason for that is that iterating over all of the processes in the
system is not a trivial task.  You use different mechanisms in Windows
NT and Windows 9x.  I added the '-f' option to kill and the '-W' option
to ps a while ago to accomodate people who wanted to operate on
non-cygwin processes.  Both of these options came out of a rewrite of
cygwin's process handling code.

However, the fact that ps can report on non-cygwin processes and kill
can terminate them does not mean that these processes magically become
UNIX-like.  You can't send a "kill -HUP" to them.  You can't STOP
them.  They have to be cygwin processes to do that.

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

Hopefully, you are now fully educated.

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

Possibly.  Please provide patches to the tools to test your theory.

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

I used to work at a company that provided VMS functionality for Windows.
In VMS, paths look like this:  sys$diskc:[windows.system]kernel32.dll .
Guess what?  It had problems with translating backslashes, too.

As I keep saying, apparently), the Cygwin DLL understands MS-DOS syntax
just fine.  The UNIX tools which are part of the Cygwin package do not.

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

I always consider patches that extend functionality.  I can't testify
that the cygwin zip maintainer would be amenable to a patch or not.

cgf

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]