Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com X-Info: This message was accepted for relay by smtp02.mrf.mail.rcn.net as the sender used SMTP authentication X-Trace: UmFuZG9tSVa1Oz33tgFO/hh5k7ezyQg/LtZhw1fJx5r4LdSN0O3OJdFqeCqzGng9 Message-Id: <4.3.1.2.20030112220057.0370eea8@pop.rcn.com> X-Sender: lhall AT pop DOT rcn DOT com Date: Sun, 12 Jan 2003 22:21:33 -0500 To: "linda w \(cyg\)" , From: "Larry Hall (RFK Partners, Inc)" Subject: Re: Hindsite, moving forward, concepts...? In-Reply-To: <004001c2b9bd$ca7073c0$1403a8c0@sc.tlinx.org> References: <4 DOT 3 DOT 1 DOT 2 DOT 20030111143529 DOT 036c3f08 AT pop DOT rcn DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 05:07 PM 1/11/2003, linda w \(cyg\) wrote: > However the good news is that with the emphasis on applications maintaining POSIX compatibility -- no one >should be *relying* on "//" having a special meaning. If you mean programmatically, I'd say that's probably true. Some may have created scripts that make this assumption but I don't see that as a major issue. >That being the case, one could choose, in the present, to do a >simple hack (in the minimal case) to change the smb-share prefix >from "//" to "/smb/". Theoretically, this >should break nothing. unless they have hard-coded paths. Right, 'theoretically'. >If transitioning of current CYGWIN customers who may have >hardcoded paths is a concern, then a transition plan could be >put into effect (dates TBD): >1) string in envvar CYGWIN, maybe, 'SMB_PRFX="//"'. > This could be added to any "update" if not defined, or > set as 'SMB_PRFX="/smb/"' in new installs or set > to SMB_PRFX="" by users who want to do their own mounting. >2) When automounting SMB shares is available, then can > default SMB PRFX="" in new installs. Warning in console > login shells of "SMB_PRFX" being deprecated in favor of > automount usage. >3) Base install includes smb-automount setup. Usage of SMB_PRFX > generates warning about being ignored/obsolete and to use > automount for smb references (with default "/smb"). >4) ...after a few years...remove check for SMB_PRFX... Right. This could be a way to phase out the UNC path convention if this was desirable. >Steps can be skipped/merged; it may be decided that it is a non-issue and just do it. > >For Win32 paths -- again, going with full Win32 compatibility >seems logical since it is the only standard that assigns >meanings to ":\" usage in the Win32 world. Again, if *really* >needed, one could use a similar transition plan to allow >conversion of apps that make assumptions about C:foobar not >having the standard Win32 meaning (as previously shown, this >is not a property of CMD, and is 'honored' (wherever it is >implemented) in, AFAIK, all of MS's programs. > >Any issues only affecting Win32 path usage would be unlikely >to affect POSIX-compliant programs using preferred-character-set filenames. > >Logical? Not asking, necessarily, that anyone implement it -- >I'm only engaging in a concept discussion. Actual implementation -- >well that may never happen, or may -- may be done by someone >expert in the various areas affected, or done by me (in all my loads of spare time...*cough-cough*). Logical, yes, in terms of reaching your stated goal. Whether that goal is desirable as a whole measured by the community's usage preferences, patterns, and needs, that wouldn't be for me to say. ;-) Of course, the real hitch is the resource to implement, which you acknowledge. As you know, lot's of things can sound reasonable, logical, and even compelling in theory and yet still be abysmal failures once implemented. But having something implemented gives the entire community a concrete item to review, reform, critique, and accept/reject. It's generally a very successful route to getting new functionality in Cygwin. I recommend it if you're motivated to implement some functionality. >I'm trying to focus on what I believe would be useful for the >Cygwin toolset to allow for gnu-linux tool porting for the >purpose of using them interactively/transparently in a win32 >environment _and_ providing a *nix-POSIX compatibility layer. I understand. I'm not sure that I concur with your assessment the current needs for this work but I'm quite willing to evaluate it based on the merits of it's implementation. Not to 'scare' you of course but changing behavior of the Cygwin path handling code is not a task to be undertaken lightly. This area has allot of logic to parse the various path forms already handled plus POSIXy emulations. Any changes there must be rigorously tested for correctness and performance (i.e. no worse performance than now). But if that doesn't scare you ( :-) ) then I'd recommend you take the next step and start poking around in the code. It really is the best way to understand the details of what's there and formulate a real plan of attack. Good luck, Larry Hall lhall AT rfk DOT com RFK Partners, Inc. http://www.rfk.com 838 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/