Mail Archives: cygwin/1997/01/02/12:47:30
First off, congratulations and many thanks to all the folks who have
obviously put in much effort in porting the GNU tools/environment to
the Windows 95/NT platforms. I've had a good deal of initial success
at using gnumake along with bash and friends to allow us to use a
common build environment for the NT port of a large, multi-platform
Unix application. My experience with the tools and documentation so
far is that they have all been first rate!
Now for the subject of this post:
I think it was noted some time ago that support for UNC path names
might be problematic because of the convention for '//' being used to
prefix a drive letter (e.g. '//x/' == 'x:\'). It seems like this
might be unfortunate, especially since I'm not sure I understand the
real need for the '//' drive letter convention. For example, what is
the advantage to using:
//x/foo
when all the utilities understand:
x:/foo or x:\\foo
in the (bash) shell and
x:\foo
in cmd.exe?
Especially when there is also the option of using the mount command:
mount x:/ /x
to get:
/x/foo
(This seems like the most elegant solution to me.)
Is the extra convenience of '//' really worth losing the ability to
do things like:
ls '\\server\shared' (or: ls //server/shared)
where '\\server\shared' is the UNC path to the "shared" directory
resource on server "server"? Remember:
dir \\server\shared
is perfectly legal and often quite convenient under cmd.exe...
I realize it may be too late and/or too unpopular to undo the '//'
convention, but perhaps support for UNC path names can still be worked
in? It could even work with the same syntax as long as you don't have
servers named "A", "B", "C", etc!
I hope these observations/suggestions can somehow be useful.
--
Ed Huott
Pinebush Technologies, Inc.
<huott AT pinebush DOT com>
-
For help on using this list, send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".
- Raw text -