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 sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Message-Id: <4.3.1.2.20010926123559.02456e78@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: Wed, 26 Sep 2001 13:06:43 -0400 To: "Keith Starsmeare" , From: "Larry Hall (RFK Partners, Inc)" Subject: Re: //c - Ouch! In-Reply-To: <000f01c146a8$d51c3450$5d754789@edinstonehaven> References: <4 DOT 3 DOT 1 DOT 2 DOT 20010926104927 DOT 016fb790 AT pop DOT ma DOT ultranet DOT com> <4 DOT 3 DOT 1 DOT 2 DOT 20010926113933 DOT 024717e0 AT pop DOT ma DOT ultranet DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 12:32 PM 9/26/2001, Keith Starsmeare wrote: > > I'm not suggesting that your idea is bad. Indeed, it certainly does have > > merits. However, like you, I wouldn't know where to put this so that it > > would address the need. > >How difficult would it be to add a warning into setup? I must download that >code someday!! Shouldn't be too bad for someone who understands C/C++ code. If you're interested in pursuing this, perhaps you want to consider providing some generic facility to apprise users of important changes as part of the installation. If this appeals to you, you may want to check the email archives. There has been one discussion, started with a somewhat tongue-and-cheek remark (of mine) that generated allot of discussion and some good ideas along this line. > > Also, I will say that I don't recall a single query on this list since > > the change that has indicated this is a major problem. Everyone seems > > to be taking it in stride. > >I'm worried that people won't realise why cygwin's suddenly going so slowly, >and they're too shy to post, or just not interested in joining the mail >list, and so they just plod on until they finally discover that //c no >longer means what it used to mean! It's hard for me to believe in a silent majority after being on this list for a while but that's just my cynicism creeping in again! ;-) I'd be surprised to find out that someone who notices poor performance in Cygwin doesn't report it to this list, especially if they compare it to the performance in a DOS prompt. But this is all hypothetical so it doesn't mean much. However it seems to me that the concern you're voicing here is that of using "//" in paths. The old // notation is only a very small piece of that. Perhaps another mechanism or message is needed to combat this general issue, since it's not related to this particular release. People need to be made aware that "//" in Cygwin is the same as "\\" in Windows environments. Both invoke UNC semantics, which implies network support, which implies overhead. If people learn this, then they will understand why using "//" in paths is a bad idea, regardless of whether it used to be supported syntax for drive access or not. But I wouldn't recommend tackling this issue with some addition to setup.exe. Such a notice would need to be part of *every* release. So maybe any notice you might want to add to setup for 1.3.4/5 would simply note that old // notation isn't supported and this is now equivalent to a UNC path, with the pointer to the appropriate document to explain UNC. Well, I expect I'm getting a little ahead of you! ;-) If you want to pursue this and need further input from me, just ask (though I turn into a pumpkin at the end of the week for 3 weeks so the window is narrow! ;-) ) 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 -- 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/