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 From: "linda w \(cyg\)" To: "'Gurusamy Sarathy'" , "'Jos I. Boumans'" Cc: , Subject: RE: Repost, different list...File::Spec, Cygwin, Syntactic vs. Semantic path analysis Date: Sun, 5 Jan 2003 23:55:09 -0800 Message-ID: <000a01c2b558$ef6a3620$1403a8c0@sc.tlinx.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal In-Reply-To: <200301052041.h05Kfjp04450@smtp3.ActiveState.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal > >So I think a fix could to change F::S::Win32 to convert all win32 > >pathseperators to unix pathseperators, and hand it off to F::S::Unix > >to do the actual catfile(), etc calls... > > Sounds fine, as long as we still do the right thing when > handed paths with backslashes in them (i.e. result should > have backslashes too). I'm not much worried about how the > internal implementation is done (at least for now :) as long > as the interface and semantic guarantees are correct. > > So yes, I think we're generally in agreement here. === um...maybe...I don't mind normalizing converting all A to B, but it could easily be *wrong*. I can have "\" in a unix pathname, and i can have "/" exported in an arbitary sharename that *isn't* a directory separator. Yes -- they are both edge cases, but trying to come up with a rule that doesn't consider what will happen in the 'edge' cases is like not programming to check for buffer overruns. Hopefully we can think farther ahead... -l -- 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/