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 Message-ID: <3B39625A.9080603@gruntose.com> Date: Wed, 27 Jun 2001 00:34:34 -0400 From: "Fred T. Hamster" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.1) Gecko/20010607 X-Accept-Language: en-us MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Cygwin: Interoperability Is Important (was Cygwin: Open or Closed System, etc) References: <3B391600 DOT 6080408 AT gruntose DOT com> <3B3947DE DOT 7009F7DA AT ece DOT gatech DOT edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit ooh, very spicy. i suppose i deserve it (full posting attached below). however i am also interested in improving the cygwin project and making things better for the world. i think you might have missed that part of the conversation (referenced in your posting) had drifted away from zip in specific to cygwin path handling in general. i believe that the examples i provided for 'ls' demonstrate that this issue is not limited to the zip port. and as far as what i can see from reading the manual (user guide), handling ms dos pathnames is a design goal for cygwin. as far as what cygwin _is_, my interest is currently focussed on the core functions in the cygwin dll, and what could be modified to hande both types of pathnames. i am willing to dig through the source and find that out, but i am also extremely pre-occupied with a software release at the office at this time. thus my earlier offer mentioned i could start looking into zip / glob later in the summer. this path parsing has been done successfully before. i mentioned the info-zip dos/windows port. i did previously use that version of zip instead of the cygwin version, since it handled these path differences well. i had to stop using it when i started using cygwin, since the info-zip port does not understand the cygwin drive notation of /cygdrive/X. thus, i could not really mix and match cygwin tools (find, grep, etc) with infozip's programs. also, the presence of the cygwin version of zip is awfully attractive as a single target for creating zip files at the command line, when i rely on so many other of the pieces of cygwin. i apologize if i've personally offended you (or any of you listeners). i do hope that i've kept my postings in line with the acceptable language and decorum in the list, and apologize if i have not. as mentioned earlier in other threads (blunt tools), email does not convey all nuances of the intended thoughts and is fairly easy to interpret in a way other than desired by the author. regarding a few specific questions, Charles Wilson wrote: Is "a:fred" a filename with six characters (on unix, yes), or a four-character filename in the current directory under the a: root (remember, windows/dos keeps multiple "current directories" -- one for each root) And let's not even get started on the multiple streams allowed when using NTFS -- "a:fred" can be "fred" on the a: drive, but can also mean the file "a" in the current directory, but accessing the stream named "fred" within the file "a". "a:fred" is what i used to call a degenerate path name, since it uses non-alpha-numeric and/or non-underscore characters. but, yes, that's a totally valid pathname under unix (and NT/etc). for win32, however, i would previously have said it's clearly the file named "fred" in the current directory on drive a. i can't claim that with certainty now, considering your mention of NTFS streams. i've not encountered that usage you're describing yet. is that accessible in command prompts? Charles Wilson wrote: Now, YOU come along and complain that it isn't good enough, but you're not going to dig in the the source code and provide a patch. And then accuse me (or the good folks at Red Hat) of "marketing hype". oops, see above (and in previous posts) for my offer to look into this later this summer and provide a patch. regarding marketing hype, all i did was ask a question. i find statement A in the user guide, which i was directed to from the cygwin FAQ in my search for more information. statement A seems to contradict what several members of the list have been saying regarding cygwin's treatment of windows pathnames. after these repeated statements from list members, i get a bit curious as to whether this part of the manual is well-known; i ask whether there is a real commitment to the statement or not. in my world, there is truth and there is marketing hype. i'm sorry that that part of my nature didn't translate into english better, and was instead interpretable as some kind of slam of redhat or cygwin (or you somehow; however i didn't actually know you existed in the role of zip maintainer until i got this post from you). i'm not going to sing redhat's praises to prove my loyalty, but i do have five machines here running linux as servers and/or workstations, and they're all redhat. Charles Wilson wrote: But I'm not going to waste my time developing functionality that is redundant, when there are several already-extant ways to get your desired behavior: cygpath -u cygpath is probably a fine solution for specific commands that one wants to create aliases for, but it is not really a general solution to the problem being described. using cygpath as a solution seems to require me to wrap every execution of cygwin binaries (from command prompts, 4NT prompts, etc) with a call to cygpath, which is a bizarre extra step. how does that really support interoperability between win32 and cygwin programs? it seems to be relegating win32 paths into the sub-basement of support. and in particular, most of my own scripts are portable between unix, win32 and cygwin; i don't want to include any kludges that injure that portability. i am driven to contemplate these things because the reality of my world at the office is interaction with that same braindead operating system, win32, and its abysmal filename conventions. don't get me wrong, i don't like them either. but i cannot just toss these concerns off as being some aberrant love of mine for win32; they are concerns that just come up repeatedly from using cygwin in a real production environment and relying on it almost exclusively for our unix support on win32. i will definitely see what i can do to examine the path handling in zip. cannot do immediately. soon. however, if it is already decided that: zip bats c:\*.bat must fail to maintain compatibility with unix, whereas: zip bats c:/*.bat can succeed (as it currently does in cygwin's zip), then i see no possibility of reaching a compromise. having the first command work properly and zip up all the batch files in c:\ is exactly what i would want to implement. in unix, the path "c:\*.bat" literally refers to the file with those exact characters. but this same kind of quibble is true of the second usage also; in unix, that pattern means all files ending in ".bat" in a subdirectory called "c:" under the current directory. if cygwin is maintaining full unix pathname compatibility, then why is it appropriate for the second usage to understand windows style paths, whereas the first must fail? again, i am not focussing exclusively on zip, but the behavior of many cygwin binaries regarding win32 style paths is similar. i understand if you don't really have time to look into this right now either. i wasn't ordering anyone to do anything; i have no power over cygwin or redhat, except what little power is conveyed by any rational arguments that i can come up with to support my points. i apologize if my reasonings are insufficient to illuminate the situation any better for those who may not understand the viewpoint of people required to actually straddle the worlds of win32 and cygwin, rather than being able to run entirely within the cygwin environment. thanks, fred. ps: i dread to even open the can of worms that is case-sensitivity vs. case-insensitivity in the file system support. -- _____ chosen by the Nechung Oracle Program [ http://www.gruntose.com/ ] _____ It is only when they go wrong that machines remind you how powerful they are. -- Clive James, in "The Observer", 1976 _____________ not necessarily my opinions, not necessarily not. _____________ Charles Wilson wrote: >"Fred T. Hamster" wrote: > >> All tools may be used from the Microsoft command line prompt, >>with full support for normal Windows pathnames. >> >>that text would seem to indicate fairly strongly that cygwin is actually >>intended to support "normal windows pathnames" after all. a big issue >>for me at least is that cygwin does not in fact support "normal windows >>pathnames" currently. >> > >What is "cygwin"? That seems to be the core problem here. cygwin, the >dll, understands and supports normal windows pathnames. zip, the tool >that happens to run under cygwin, does not. bash, the tool that happens >to run under cygwin, does (in certain circumstances). > >So, does "cygwin" support normal windows pathnames? > >Maybe. Yes. No. I dunno -- depends on your definition of "cygwin". > >So, *why* does zip not support normal windows pathnames? Well, zip was >"ported" *just enough* that it would compile successfully and work under >cygwin -- when called the same way you would call it under unix. That >is, with '/' dirseps and no drive: roots. (Note that the concept of a >multi-rooted directory structure -- a:, b:, c: etc -- is completely >foreign to most unix utilities that expect a single-root dirtree). > >Since zip must do directory manipulation itself (is this argument an >absolute-rooted pathname: yes, strip leading '/'. How many files in the >specified directory? Should I recurse? etc) it doesn't rely on >cygwin1.dll's internal pathname stuff. Should it? > >Maybe. But probably not -- because zip MUST manipulate the pathnames -- >you want it to strip the leading A:/ (cygwin1.dll won't do that; >root-stripping behavior is not general purpose. Root-stripping is unique >to archival tools) > >There are *native* ports of zip that handle root-stripping with "normal >(braindead) windows pathnames". Why do extra work (hours of effort) >when, for an additional 50k of disc space the user can download and >store "doszip" and use that for "normal windows pathnames". There's no >benefit -- and great possibility of harm, since these changes can screw >up the "normal UNIX pathname" handling in cygwin-zip. > >Is "a:fred" a filename with six characters (on unix, yes), or a >four-character filename in the current directory under the a: root >(remember, windows/dos keeps multiple "current directories" -- one for >each root) And let's not even get started on the multiple streams >allowed when using NTFS -- "a:fred" can be "fred" on the a: drive, but >can also mean the file "a" in the current directory, but accessing the >stream named "fred" within the file "a". > >>is that statement of support above just marketing >>lingo, or is it a real commitment? i sincerely hope that it's real. >> > >Again, depends on what you define as "cygwin". *I* don't do marketing, >or hype. *I* provide and maintain the zip package, and *my* performance >(or lack thereof) has NOTHING to do with Red Hat, RH's marketing >department, their web page, or even the cygwin project's webpage and >statements. > >I provided the damn thing because it was useful, required some effort on >my part to port, compile, and package, and I wanted others to be able to >use it rather than hoard it to myself. However, no good deed ever goes >unpunished. > >Now, YOU come along and complain that it isn't good enough, but you're >not going to dig in the the source code and provide a patch. And then >accuse me (or the good folks at Red Hat) of "marketing hype". Well, I'm >sorry, I'm a volunteer, for God's sake. I'm not paid by RH; anything I >do w.r.t. cygwin is directly time away from my dissertation. Also, *I* >didn't say anything about whether cygwin's "zip" supports the braindead >filesystem of "native" windows. > >Apparently, it doesn't. News to me -- I built it for use under >bash/cygwin, and never even *tried* to run it from cmd.exe (I despise >cmd.exe only slightly less than I abhor command.com). If you send me >patches to enable your desired functionality in zip, I will consider >them, as long as there is NO detrimental impact to zip's behavior under >bash or when used with "normal" unix pathnames. But I'm not going to >waste my time developing functionality that is redundant, when there are >several already-extant ways to get your desired behavior: > >cygpath -u >a "native" port of zip >/cygdrive/a/ > >--Chuck > -- 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/