Mail Archives: cygwin/2003/01/06/12:45:10
> -----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 <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/
- Raw text -