Mail Archives: cygwin/2001/10/18/17:12:11
Corinna Vinschen wrote:
>
> On Wed, Oct 17, 2001 at 07:23:42PM -0700, Peter Kennard wrote:
> >
> > I am really pleased now that cygwin is more complete and has the new
> > "mount" virtual file system. I can now treat all my boxes the same as far
> > as most command line oriented operations are concerned.
> >
> > But a lot of very useful apps open source, and not, written for windows use
> > the C:\blah\file path system
> >
> > A nudge to them could be offering a tiny code snippet that will:
> >
> > detect the presense of cygwin mount registry entries, if they are there
> > translate a path in a buffer from the cygwin path to the associated windows
> > path and return a flag indicating whether cr/lf translation is set on. Or
> > leave a windows path untouched.
> >
> > ret = toCygpath(const char *inbuff,char *outbuf, int maxlen);
> >
> > (the reverse would be nice too :)
> >
> > It should be completely stand alone with no dependencies on cygwin
> > dlls. This so it could very easily be installed in windows apps that are
> > not presently "cygwin" compatible, but may wish to be without being
> > dependent on it. This snippet should be commercially usable to encourage
> > it to be included in as many apps as possible.
> >
> > It would be really cool if the cygwin mount system could become a windows
> > environment industry wide shared resource and help get rid of the
> > ^%$$^#^%$^$ colon (outside of a URL) and the backslash. I know I woudl put
> > it in my code.
> >
> > I would write it if there is a concensus on it, though I'm sure the
> > fictionality is in the cygwin codebase already and it shouydl be used ;^>
>
> First of all, I think it's a good idea. But you would need at least
> two functions as implemented inside of Cygwin:
>
> cygwin_conv_to_win32_path(IN const char *posix_path, OUT char *win32_path);
> cygwin_conv_to_posix_path(IN const char *win32_path, OUT char *posix_path);
>
> or use a C++ class as the `path_conv' class in Cygwin.
>
> Unfortunately it's not there in a form which allows using it standalone.
> So, if you're volunteering to write such a function you would have to
> look through the cygwin sources and then rewrite them appropriately.
> The important stuff for the path conversion is in path.cc.
>
> BTW, "it would be nice"(tm) if such a functionality is compilable
> using MingW and VC to give the vendor of the tools a choice. Oh,
> and, "it would be nicer"(tm) if the code also recognizes Cygwin
> symlinks, both, old and new form...
A license warning: unless you develop the code for these functions in a
"cleanroom" manner -- ie. by inspecting only the documentation and
registry entries themselves, without reference to the existing cygwin
code -- then your implementations will be "derived works" of Red Hat's
cygwin. Therefore, there will be messy copyright ownership issues.
However, those messy issues can (probably) be avoided if your
implementations are released under the GPL (actually, this MAY be
required, but IANAL). Assuming that your implementations are GPL, then
they would be linked together with the client applications your are
trying to proselytize -- meaning that they would have to ALSO be GPL.
This is not a bad thing, IMO -- but it is something of which you should
be aware.
--Chuck
P.S. Let the grand GPL license flamewar begin!!!
--
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/
- Raw text -