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.
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>
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.
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.
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.
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. 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.
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?
thanks,
fred.
--
_____ chosen by the Nechung Oracle Program [ http://www.gruntose.com/ ] _____
Believe those who are seeking the truth; doubt those who find it.
-- Andre Gide
_____________ not necessarily my opinions, not necessarily not. _____________
--
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/
