[GRASSLIST:1764] Re: cygwin peculiarities

[Glynn Clements]

[CC'd to dev list.]

Richard Greenwood wrote:

> I believe that I have found the root of the problem that I outline in the 
> email below. I had been using WinZip to un-compress and un-tar the source 
> archive. WinZip apparently converts UNIX \n into DOS \n\r in files that it 
> identifies as text. I wouldn't think this should matter for C source files, 
> but I am guessing that there may be some files that are sensitive to this.

It does matter for multi-line macros, e.g.

	#define foo(x) \
		yadda_yadda_yadda(x)

The backslash has to be the last character on the line; if there's a
CR between the backslash and the newline, it's an error.

Also, a few source files had string literals with embedded newlines
(they have been fixed in 5.0.3); in that case, the CR would be part of
the string literal.

Also, not all of the files which comprise GRASS are C source code.
There are the Gmakefiles (from which Makefiles are generated), plus
code in Fortran, lex, yacc, Tcl, shell scripts, and probably some
other cases which I've overlooked.

However, none of these are related to your problem. I'm certain that
was caused by CRs in the $GISBASE/etc/element_list file. That would
result in the descriptions ending with a CR, so the code:

> >         fprintf (stdout," %-*s ", len, list[n].desc[i]);

will print a space, followed by the description, including the CR at
the end, then the trailing spaces. On most terminal emulators, the CR
will move the cursor to the beginning of the line, so the "trailing"
spaces will overwrite the beginning of the line.

> If I use gzip and tar to unpack the archive before I build, then the 
> resulting binaries do not exhibit the problem. I have been bitten by this 
> conversion enough times in the past that I should have know better!

IIRC, WinZip has an option to disable the LF->CRLF conversion.

In any case, it's worth considering whether G_strip() should treat CR
as whitespace (hence the CC: to the grass5 list). Currently, only
space and tab are treated as whitespace.

Or maybe we should just consistent use open(..., O_BINARY) and
fopen(..., "rb") so that GRASS will work on Cygwin in "text" mode
(where Cygwin does automatic CRLF->LF translation), but that's likely
to be a lot of work (more significantly, it would result in a lot of
odd problems for Cygwin users wherever we miss a case).

-- 
Glynn Clements <glynn.clements at virgin.net>