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 [ ] _____

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

Unsubscribe info:
Bug reporting:

More information about the Cygwin mailing list