Mail Archives: cygwin/2001/06/27/01:59:58
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.
>
><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>
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/
- Raw text -