RE: Repost, different list...File::Spec, cygwin, Syntactic vs. Semantic path analysis

["LA Walsh" <law at tlinx dot org>]

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