This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



> -----Original Message-----
> From: Elfyn McBratney [mailto:elfyn-cygwin@sickpuppy.co.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    <DIR>          .
#   12-27-02  12:50a    <DIR>          ..
#   12-27-02  12:58a    <DIR>          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    <DIR>          .
#   01-06-03  08:30a    <DIR>          ..
#   01-06-03  08:19a                 0 LINDA~EN
#   01-06-03  08:21a                 0 does this path work
#   01-06-03  08:24a    <DIR>          dirfoo
#                  2 File(s)              0 bytes
#    Directory of \\ishtar\tmp\law\dirfoo
#   01-06-03  08:24a    <DIR>          .
#   01-06-03  08:24a    <DIR>          ..
#   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 <singlequote> 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 <colon> 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::<module>
would be Semantic validation relative to the local system.

III.
It seems like for path splitting, syntactically, "<drive>:" should always be
split into the "device" (or volume) portion -- both under win32 and cygwin --
since it can't be anything else (<drive>: is invalid under both, though
not under unix).  Also, any <colon>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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]