Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com From: "LA Walsh" To: Subject: RE: Repost, different list...File::Spec, Cygwin, Syntactic vs. Semantic path analysis Date: Mon, 6 Jan 2003 09:43:30 -0800 Message-ID: <001801c2b5ab$20576a30$1403a8c0@sc.tlinx.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal In-Reply-To: <20030106083008.4C1334385@sitemail.everyone.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id h06HjAr32525 > -----Original Message----- > From: Elfyn McBratney [mailto:elfyn-cygwin AT sickpuppy DOT co DOT uk] > I tend to agree that as windows uses the back-slash as a > default path seperator so should `normalize' but also in the > interest of compatability with windows 95 (in dos mode) as it > doesn't support the forward-slash path seperator. ---- I'm not sure I'd use Win95 as an example of what one should use for compatibilities sake -- why draw the line there? Why not Win 3.0 or ...was there a Win 1.0?...Maybe PC-DOS 1.0... Even I wouldn't choose to support anything prior to Win98SE. Too many problems... However... > > > In "cmd.exe", you can type 'dir \' or you can type 'dir "/"'. > >You have to quote the "/" so it won't be interpreted as a switch > >character -- but the underlying OS seems to not really care which you > >use and neither should Win32. > > A bit OT but dir does not support the forward slash pathsep > even when quoted: > > C:\WINNT>dir "/" > > Directory of \\ > > File Not Found --- You're right...I know I typed it in somewhere last night and it worked, but it was getting a bit late...might have mucked up and typed it into a cygwin shell...:-) Weird OT examples follow preceeded by "# "... # Oddly the following does work (WinXPSP1): # 1) # C:\PCTemp>dir "/temp/w2k" # ... # Directory of C:\temp\w2k # 12-27-02 12:50a . # 12-27-02 12:50a .. # 12-27-02 12:58a Temp # 0 File(s) 0 bytes # 3 Dir(s) 9,374,515,200 bytes free # # But not with "cd": # 2) # C:\PCTemp>cd "/temp/w2k" # The system cannot find the path specified. # # ...I'm getting a headache...let's look at the source!...um...drat...can't # do that (probably no wonder given this weird behavior). # # I have no problem with normalizing in win32 Perl changing everything to "/". # Seems best for syntax parses -- perhaps it's a bug in samba to allow this, # but just for masochism's sake I recreated my weird pathname via samba on # linux: # 3) # ishtar:/tmp/law> ls -R /tmp/law # /tmp/law: # dirfoo/ does this path work linda\'s tmp dir in weird path dir # # /tmp/law/dirfoo: # footxt.txt # --- # cmd.exe: # 4) # C:\>dir /s "//ishtar/tmp/law" ##only seems to work with /tmp also # ##exported # Volume in drive \\ishtar\tmp is tmp # Volume Serial Number is 0ADF-016E # Directory of \\ishtar\tmp\law # 01-06-03 08:24a . # 01-06-03 08:30a .. # 01-06-03 08:19a 0 LINDA~EN # 01-06-03 08:21a 0 does this path work # 01-06-03 08:24a dirfoo # 2 File(s) 0 bytes # Directory of \\ishtar\tmp\law\dirfoo # 01-06-03 08:24a . # 01-06-03 08:24a .. # 01-06-03 08:24a 0 footxt.txt # 1 File(s) 0 bytes # --- # ## w/o /tmp exported and only /tmp/law, explorer shows it but neither cmd # nor explorer can access the directory. Oddly, 'dir' doesn't show shares # for the path "//ishtar" even though it can list the contents of shares # have to use "net view \\ishtar" (or // or \\ under cygwin). # (though neither cmd nor cygwin can display contents of "tmp/law" unless # "tmp" is also shared....net view shows: # # 5) # C:\root\tmp>net view \\ishtar # Shared resources at \\ishtar # Share name Type Used as Comment # # ---------------------------------------------------------------------------- # home Disk Home Directories # share Disk (UNC) Ishtar Share # tmp/law Disk Per user tmp dir to demo psycho path # The command completed successfully. # # # Anyway...seems like "/" works on network paths except in weird cases. # Also filenames with in them created on linux get an 8.3 # translation, but if created from win32 seem to work fine -- registry magic, # I guess...(?) So it seems that 'syntactically', one can't always determine if a "/" is invalid in a straight win32 environment -- at least not when a network name is involved, but I'd agree it is pathological and should be ignored (and documented as ignored for pathological share names) So I'd suggest the following: I. Win32 syntactic normalization should always proceed to return "\". Cygwin is a Posix compatibility layer for Win32, though -- it isn't supposed to be a complete replacement/invalidation of the underlying Win32 layer -- unless one wants to declare that "e:foobar" only can reference a file and simulate "foobar\fee" as a valid file (through some mechanism). For cygwin to be a useful constructor of utils -- it should hand both Posix names *and* win32 names. Normalization can return "/" for any filename that doesn't have, say, a in it -- but ... no... I agree it should always return "/" for _syntactic_ normalization....and *document* that "\" will be converted to / even if a remote fs allows "\" as a filename character. II. The second part of this is 2-fold -- a) The other "OS"s should clean up any semantic validation of paths -- since to do so would imply that both unix and win32 and cygwin should try to verify the above described 'edge' cases as well as verify that all "//host/share" names are valid, and "x:" is a valid drive. b) Possible option to add to File::Spec, or perhaps a different File:: would be Semantic validation relative to the local system. III. It seems like for path splitting, syntactically, ":" should always be split into the "device" (or volume) portion -- both under win32 and cygwin -- since it can't be anything else (: is invalid under both, though not under unix). Also, any s in the middle of either path should through an exception. What'cha think? > > Although the win32 api supports both one takes more work as > paths containing forward-slashes are converted to > back-slashes*. I know this is being petty but if different > style paths cause problems surely it would make sense to > follow the standard the OS follows? --- Agreed. With special note: 'cygwin' is not an OS. It's a posix compatibility layer on top of a win32 OS. Posix doesn't disallow : or \ in filenames or assigning them to special meanings -- it just says that their usage is dependant upon the underlying OS the program is running on. -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/