Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com Message-Id: <4.3.1.2.20000526132953.00e6cb40@pop.ma.ultranet.com> X-Sender: lhall AT pop DOT ma DOT ultranet DOT com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 26 May 2000 13:46:26 -0500 To: Bob McGowan , "Parker, Ron" From: "Larry Hall (RFK Partners, Inc)" Subject: Re: File name syntax (WAS: RE: FW: Can not config sshd) Cc: "cygwin AT sourceware DOT cygnus DOT com" In-Reply-To: <392EB2CD.20BCE950@veritas.com> References: <200005261702 DOT KAA22136 AT athena DOT veritas DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 12:22 PM 5/26/00, Bob McGowan wrote: > > > > Which makes me wonder would a patch to cygwin be welcome that did the > > following? > > > > * Make multiple introductory slashes on a path behave as a single > > introductory slash > > * Make paths that begin with name: and contain no backslashes behave as a > > network path > > > > In other words, "///myfile" would translate to "/myfile" and > > "machine:dir/file" or "machine:/dir/file" would map to the Windows path > > \\machine\dir\file. > > > >I would endorse this, since it would make the operation of Cygwin more >'unix like'. All unix systems I'm familiar with (mostly SVR3 and SVR4 >derived) treat a '//' the same as '/./' so a path that comes up looking >like //usr/src >is handled correctly. I would speculate that this was done so the root >user's home directory '/' would work correctly with absolute path names >generated elsewhere. > >Currently Cygwin treats multiple slashes in a path (abc//xyz) in this >way, anyway, so doing so for leading slashes would also make the >operation consistent. The problem with this is it would disallow the use of UNC paths. To avoid this, care would be needed to avoid collapsing the initial "//" to "/". However, my guess is that excluding the initial "//" works against the goal that Ron was originally envisioning (i.e. the elimination of subtle errors resulting from erroneous occurrences of "//", in addition to "///", "////", etc). Seems to me like this goal may well be addressed by simply having bash handle an undefined HOME variable more appropriately, like perhaps what Earnie suggested. I see no obvious problem with the introduction of the NFS path scheme. Its a bit "non-standard" for UNIX outside of NFS circles but then again, so is UNC. Larry Hall lhall AT rfk DOT com RFK Partners, Inc. http://www.rfk.com 118 Washington Street (508) 893-9779 - RFK Office Holliston, MA 01746 (508) 893-9889 - FAX (508) 560-1285 - cell phone -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com