Cygwin: Interoperability Is Important (was Cygwin: Open or Closed System, etc)
Fred T. Hamster
Tue Jun 26 21:34:00 GMT 2001
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
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
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.
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
>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
>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
>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:
>a "native" port of zip
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
More information about the Cygwin