Re: Hindsite, moving forward, concepts...?

["Larry Hall (RFK Partners, Inc)" <lhall at rfk dot com>]

At 05:07 PM 1/11/2003, linda w \(cyg\) wrote:

<snip>

>         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 "//<host/share>" to "/smb/<host/share>".  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@rfk.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/