Re: lynx-dev cygwin patch

[Klaus Weide]

On Sun, 30 Apr 2000, Doug Kaufman wrote:

> On Sun, 30 Apr 2000 address@hidden wrote:
> 
> > > +#if defined(DOSPATH) || defined(__CYGWIN__)              /* thanks to 
> > > Hiroyuki Senshu */
> > >  
> > Is this done at the right place?  Are there other uses of DOSPATH that
> > affect cygwin?  Would it be better do define DOSPATH for cygwin compilation?
> 
> There are other uses of DOSPATH that could affect cygwin, but
> they don't all seem appropriate for cygwin. In addition, I
> believe that we agreed that DOSPATH is deprecated, since it
> had been used for things other than the path itself. I think
> we are now trying to use individual defines (e.g. __DJGPP__
> || _WINDOWS || __EMX__ || __CYGWIN__), 

I find that quite horrible.  And it seems there are constantly
problems with keeping track of this kind of stuff, judging from
the number of patches that fiddle around just with ifdef-conditions.

> so that quirks of each system can be addressed individually.

Many of them don't seem to address quirks of the "system" identified
by the preprocessor macro (in this case, the cygwin environment), but
some preference that someone (using that environment) thinks is
more appropriate.

The "use cp or not" patch is a good example for this.

I am not currently a user of cygwin.  But if or when I become one,
I image I'll be using it to get an environment that is as much as
possible "Unix-like".  I certainly don't expect as much as possible
"DOS-ish" behavior.  I'd expect a "cygwin port" of lynx to use the
for-Unix code as much as possible (better tested, less bugs IMO),
and let cygwin do its job of emulating a Unix-like environment.

Others may disagree (they apparently do), but that shouldn't be
forced on all users of cygwin.

> At least the way that
> I have cygwin set up, it doesn't accept DOS-style paths by
> default. "D:\" is mounted to "/d/", and "D:\test\foo.bar"
> is addressed as "/d/test/foo.bar". 

So if all the input to lynx is in Unix-style form, and output is
only fed to things that understand Unix-style output, where is the
problem?  I'd expect lynx to work in that mode as it does on a Unix-like
OS.  Use of cygwin, alone, shouldn't force use of DOS-ish conventions
for filenames (for output), or even recognition of them on input.

> I believe that there are
> cygwin functions to convert, but they would have to be inserted
> appropriately into the unix code (cygwin_conv_to_full_posix_path()
> and cygwin_conv_to_full_win32_path()). 

I disagree with the premise that all users of a cygwin-using lynx
would want or need such extra code.

> There are some defines in the
> code for "__CYGWIN__ && DOSPATH", so there must be times that both are
> used.

Just 'cause it's in the code doesn't mean it makes sense...

> I am not sure who else is working with the cygwin code. I have been
> spending most of my lynx time looking at DOS related problems and only
> occasionally playing with cygwin.

I am using neither; but I like the idea that I *could* use a lynx
that's as-much-as-possible like the Unix lynx, if I went to use the
cygwin environment.  Making all kinds of DOS-ish behavior depend on
(just) __CYGWIN__ sabotages that, uhm, dream.

Where conditional compilation is necessary, there should be sensible
HAVE_* or NEED_* or WANT_* macros that allow to make a choice, not
something like
   (__DJGPP__ || _WINDOWS || __EMX__ || __CYGWIN__)
that forces one kind of behavior on all users on some set of platforms
(and is typically without any documenting comments in the code).

Something like good old "DOSPATH" isn't bad because it is less specific
than (some combination of) __DJGPP__, _WINDOWS, __EMX__, __CYGWIN__.
DOSPATH is bad because it has never been defined what it's supposed
to mean, and it had come to mean the kitchen sink of DOS-like behavior.


    Klaus