> >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/