>
> Cygwin's primary purpose is to provide a UNIX environment for
> Windows. Although it can be used in other ways, the basic
> purpose is not to provide a stepping stone to helping port
> programs to native Windows. Things like Win32 path names and
> accommodating pure-win32 processes are
> *always* of secondary importance wrt getting the UNIX bits right.
---
Would you please contact RedHat and have them change the stated purpose of the
project? It's very confusing:
At http://www.redhat.com/software/cygwin/, it says:
"Cygwin is a set of powerful tools to assist developers in migrating applications from
UNIX/Linux to the Windows platform."
That's the first and primary purpose listed. Later on, it says " In addition, it
provides for a standard UNIX/Linux development environment on Windows including APIs
and command shells. The Cygwin.dll library, included with Cygwin, delivers the
interesting subset of UNIX SVR4, BSD, and POSIX APIs to enable quick ports of
UNIX/Linux applications to the Windows platform."
A stated project *feature* (in the next paragraph) is:
"Standard Windows command line tools can even be intermixed within the UNIX/Linux
shell script environment to administer the Windows system. Over the years, UNIX/Linux
system administrators have developed a large toolbox set of management scripts for
their UNIX/Linux machines. Cygwin provides the ability to continue using these scripts
on Windows machines."
In order to be able to seamlessly integrate cygwin tools with Windows tools in
the same shell script environment and apply linux scripts to windows machines --
seamlessly, the linux scripts need to understand Windows pathnames.
Now maybe you'd like to change "Cygwin" to be something other than what it was
intended. If you really want a linux only environment -- I have had pretty good
success with SuSE over the years. I've even regularly used Vmware to run Windows on
top of my linux machine -- for
*years* to provide Win access to my linux files and vice-versa.
You are trying to change the original design goal of Cygwin by "vehement
assertion" -- much like Microsoft tries to change the realities of software ownership
and first-sale doctrine by "vehement assertion and threats of "legal bullying" (that
logically, would eventually fail under current law...but in our system, it's those who
have the most money to pay their warriors (lawyers) full-time to harass you that win
their point by forfeit -- not court decision). MS, historically, on every patent case
that they kenw they didn't stand a chance on, when the person was stubborn enough try
to 1) buy rights to use the patent, 2) buy the patent, 3) buy the company that owns
the patent, 4) negotiate business deals with the company that specify MS gets the
patent (or use thereof) if they fall through -- and make the deal look attractive
enough that the company is distracted by the 'gold' (fake gold) that appears to be in
the deal for them. Then MS withdraws support, the company dies and MS gets the patent
-- again by forfeit. So far, no one has withstood all of MS's patent acquisition
tactics. It's not that MS is *right*, they just have the loudest and longest lasting
voices -- PR department that try to reframe people's idea of what is normal. If you
get enough people to believe a lie for long enough, it can become accepted as truth.
In this situation, your vehement assertion not withstanding, the origins of
the Cygwin project are clearly stated and they are not what you are claiming them to
be.
>
> >Might that not imply some minimal understanding of the Win32
> >environment so as to integrate as seamlessly as possible with such?
>
> Nope. It's supposed to isolate you from the windows
> environment. In theory, you shouldn't have to know or worry
> about the :\ nonsense.
---
More vehement assertion of incorrect facts.
> Understanding that the OS uses :\ specially, and that the
> filenames are case preserving but case insensitive, is, of
> course, necessary.
---
No more necessary than it is for you to run Windows. You could write your own
file system layer -- port ext2 to Windows. Write your own API to the file system. At
the *very* least, you could use a UTF-8 type encoding scheme to encode a 'colon' as
some other sequence of bits. Under NT, there is a local policy that specifies whether
or not to enforce case ignorance on all file systems -- you can *choose* not to have
case ignored on subsystems that provide upper and lower case. Perhaps FAT32 as well
-- just might not be a backward portable FS to Win98---but
NTFS...*very* likely.
> Understanding that double slashes at the
> beginning of a path are special is good sense for any
> portable program.
---
There you go again, making relative assertions about "good/bad" again. It's
common practice to define a $(ROOT)/foobar underwhich to build or install a program.
It is common to have ROOT=/ when you want to install it on a live machine. It is
*expected* that double slashes "//" will be treated as "/". Thinking "//" is special
only shows the corrupting influence Win32 has had on your thinking. If you grew up on
unix, you'd know that "//" = "/".
It appears you may be having the 'reactive' feelings about Win32 of a
recovering Win32-aholic. Once you've seen the 'light' of linux, Win32 is now the
"villian" to be despised. Only by viewing linux and Win32 as different in design,
both with strengths and weaknesses will you truly be free to pick what is truly useful
from both, and ignore the rest. But to be in "reactive" mode against Win32 (as are
many Open Source and Linux affectionados (and myself as well in times past), is to
ignore the things Win32 does right or better than the Open Source/Linux alternatives.
You will never truly be free of MS's influence as long as you are emotionally
attached one way or the other.
> Again, spending a lot of time worrying about what will happen
> when a user types in a MS-DOS path name is uninteresting.
---
To you -- not to the Cygwin project nor me. You are a divisive element
seeking to create division where there need be none. Rather than unification, peace
and healing, you want war. I suppose you also voted for George Bush.
> Document whatever warts that Cygwin has and move on. Or
> provide patches to rectify any egregious behavior you find.
> Just lets not spend too much time on this subject in the
> cygwin mailing list.
---
Agreed.
> >But for that to be
> >happen, the tools have to be able to parse standard Win32
> pathnames as
> >well as posix-ish/*nix filenames.
>
> Why? Just use UNIX paths.
===
Because Win32 users won't understand them and linux/gnu utils won't seamlessly
integrate into the win32 environment -- the first and foremost stated goal of the
project.
> Maybe your mom is special.
--
My mom and dad are special -- they taught me to question "common knowledge"
and "vehement assertions". In short, they tried to create something akin to "critical
thinking" skills that most adult americans lack. Dogma is an anesthetization of
"critical thinking".
> My parents have little, if any,
> understanding of slashes, so if I told to always type 'mv
> /cygdrive/c/foo /cygdrive/c/bar' they would dutifully type
> that.
---
Just like they'd jump off a cliff if you told them to, no doubt?
My parents -- my dad has been trying to use and learning to use a computer for
about 5-6 years (he'll be 80 this year). My mom got her own computer about 2-3 years
ago (she'll be 72 this year). Something else the passed on to me -- a desire to keep
learning. Something most adults tend to stop doing, unless they have to, as soon as
they get out of school. I take classes and read textbooks from diverse fields to try
to balance out my engineering background and profession: law, medical, comparative
religion, dance, sociology, psychology, finance, politics, philosophy as well as
computer related courses as desired. I try to get the widest scope of knowledge I can
to see things outside of the perspective of individual or group dogma to be able to
create ideas and make decisions outside the 'box'.
> If I tried to explain how they could type
>
> c:
> cd \foo
> d:
> c:
> pwd
>
> and still be in c:\foo their eyes would glaze over.
---
I'm sorry to hear that.
>
> It's hard to understand how this could be a really big issue
> for a naive user anyway.
>
> >>Whatever you do *please* do not make the mistake of
> converting slashes
> >>to backslashes in anything that is seen by cygwin functions.
> >
> >--- And your reasoning not to convert a path that appears to be a Win
> >format: C:\foobar/smellypath/file or \\sysname\share/dir/subdir to a
> >standard winpath of all backslashes if the user asks for a canonical
> >path? You say:
>
> I said previously that if cygwin sees a path with a backslash
> or a colon it is considered to be a windows path. So, if you
> change /foo/bar to \foo\bar or c:\foo\bar you will cause
> problems. That is what I meant. As far as cygwin is
> concerned, \foo/bar and \foo\bar are "equivalent", however.
> The presence of the backslash causes the file to be treated
> as a windows path.
---
You just contradicted yourself. You said they are "equivalent" but then you
say the "\" causes it to be treated as a "windows" path [which may be, as you pointed
out earlier, different, due to, say, the presence of a cygwin mountpoint of
C:\<cygdir>\foo on /foo. They are not equivalent -- as you already have convinced me.
You won't easily convince me to the contrary now, since (of course), I logically
verified the statement when I first encountered it.
>
> So, I don't want to see any of these conversions as part of a
> canonicalization:
>
> Path Conversion ## My Comment
> /foo\bar /foo/bar ## agreed
> /foo/bar \foo\bar ## agreed
> c:/foo/bar /cygdrive/c/foo/bar ## agreed
> c:\foo/bar /cygdrive/c/foo/bar ## agreed
> /cygdrive/c/foo c:\foo ## agreed
>
> These are ok:
>
> path conversion
> /foo\bar \foo\bar ## Nope -- "foo" could be a
## mounted cygwin file system
and
## changing the initial "/" to
"\"
## could change file handling
## semantics
> /foo/bar /foo/bar ## agreed (noop)
> c:/foo/bar c:\foo\bar ## agreed
> c:\foo/bar c:\foo\bar ## agreed
> c:\foo\bar c:/foo/bar (presence of colon means win32)
## Yes and no -- did you mean
## C:/foo/bar -> C:\foo\bar?,
## since ":" means win32 and
## therefore, "\"
> /cygdrive/c/foo /cygdrive/c/foo ## agreed -- as well as:
## /cygdrive\c\f ->
/cygdrive/c/f
>
> >I think we are in agreement on "/home/myhome\mybin\myfile" being
> >canonicalized to use all forward slashes.
>
> We are not in agreement. If cygwin sees a backslash it
> assumes it is a windows path.
## I may not be correct, but
## what does it mean to have
## a windows path mounted in
## the middle of a linux path?
> Mounting remote shares works just fine. I do it all of the
> time. I'd be lost if it wasn't possible. Cygwin's mount
> table is just a translation table. There is no magic that
> would preclude using remote paths.
---
Perhaps an example would explain the misunderstanding:
law/scripts> ls //ishtar/share/music/new
law/scripts> ## empty dir
## verify write access to music
law/scripts> mv //ishtar/share/music/new //ishtar/share/music/new2 law/scripts> ls -d
//ishtar/share/music/new* //ishtar/share/music/new2/ law/scripts> mv
//ishtar/share/music/new2 //ishtar/share/music/new
## verify write access to 'new'
## and create mount point
law/scripts> mkdir //ishtar/share/music/new/windows
law/scripts> ll //ishtar/share/music/new ## is it what we expect?
total 0
drwxr-xr-x 2 law Domain A 0 Jan 8 13:30 windows/
## now for the mount:
law/scripts> mount 'c:\windows\' //ishtar/share/music/new/windows
mount: //ishtar/share/music/new/windows: Invalid argument
## :-(
Looks like 'bad' magic to me. Something is protecting the remote path from being
mounted. I can't even do a mount that would be allowed under linux:
tara:root# smbmount //ishtar/share /mnt
Password:
tara:root# mount |grep smb
//ishtar/share on /mnt type smbfs (0)
tara:root# mount |grep windows
/dev/hda2 on /windows/c type vfat (rw,nosuid,nodev,uid=108)
tara:root# mkdir /mnt/music/new/c ## better dirname
tara:root# mount /dev/hda2 /mnt/music/new/c
tara:root# ls /mnt/music/new/c/windows
./ control.ini* progman.exe*
../ convmem.txt* progman.ini*
3cwmunst.exe* convpack.isu* protman.dos*
...<a win98 windows dir listing>...
---
I dunno -- seems to me that you can't do a cygwin mount on a remote drive.
Even with //ishtar/share/music mapped to a drive "M", I still
get:
law/scripts> ls M:/new
c/ windows/ ## oops, forgot to rmdir 'c' from tara
law/scripts> mount 'c:\windows\' M:/new/windows
mount: M:/new/windows: Invalid argument
>
> Hmm. I would think that my vote would count very highly in
> the matter of what is right or wrong for cygwin.
---
Maybe so, maybe you own cygwin...I don't know. I'm only some random idiot
that was trying to use it for the defined purpose on the RH Cygwin page -- porting
tools to the Win32 env. The specs may be wrong -- you may be God for all I know, but
I would blythely argue with God if I thought he was wrong on something. These issues
should be decidable by logic and logical design decisions, not emotional or vehement
argument.
>> >If File::Spec moves, in general, to being 'Syntax' only, then has a
> >different decompose function for Semantic analysis then the default
> >would not to treat /cygdrive/<drive> special unless one parsed for
> >"semantic" analysis -- in which case, all mount points
> should be broken
> >apart with the right-most mount point being the first 'device' name
> >split off (with the possibility, with nested mounts, of there being
> >more calls to the semantic decompose function to get at all the
> >separate devices (if needed) -- though usually for
> rename/copy purposes
> >one wants the device the targe file/dir would be on, thus the right
> >most path component that is a file system.
>
> If File::Spec deals with mount points then it should be able
> to handle /cygdrive and the rest of the mount table just
> fine. /cygdrive entries show up in the mount table. You are
> trying to move things into an esoteric realm.
---
Maybe...I live on the edge quite a bit...:-)
> I'm trying to
> show where there is (unsurprisingly) correspondence between
> UNIX and Cygwin. So, whatever UNIX does with a mount table
> should be more-or-less applicable to cygwin.
---
Gotcha! I very much agree -- a symantic parse of a unix path
should yield up fs's in the 'volume' field, though not with a
'syntactic' parse.
> You can worry
> about semantics and syntaxes over in the UNIX realm. If the
> perl gods decide to tweak something there, I'm happy to let
> cygwin hitch a ride on their decision.
---
Exactly -- no problem.
> Anyway, I've said my piece here. I'll sit back and watch
> what happens. If the end result is something that breaks
> things and people start complaining, we can always fix the
> problems and I can always say... Nah. I wouldn't do that.
----
Well, Houston, we have a slight problem here. But it's cygwin only, so as not
to clutter the perl list w/non perlese.... (somehow I felt a discussion of what was
appropriate for cygwin in perl as some merging of unix/win32 functionality was
appropriate for both lists...)
But suffice it to say that the semantics of "\" meaning it
is a "win32" path may be getting misapplied or confused somewhere. While I really like
the cleanliness of the Christopher's idea of "\"
meaning "win32", it may not be so clean...but maybe I'm just confused...I never
know...:-)
-linda
--
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/
