Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Date: Wed, 27 Jun 2001 01:54:44 -0400 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: two problems with cygwin's zip Message-ID: <20010627015444.M19058@redhat.com> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <3B390298 DOT 6030301 AT gruntose DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.11i In-Reply-To: <3B390298.6030301@gruntose.com>; from fred@gruntose.com on Tue, Jun 26, 2001 at 05:46:00PM -0400 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. > > >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. > 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/