[GRASSLIST:1763] Re: cygwin peculiarities

[Richard Greenwood]

Glynn, et al;

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.

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!

Regards,
Rich


At 06:02 AM 11/10/2003, you wrote:


>Richard Greenwood wrote:
>
> > Hello kind list;
> >
> > I am seeing some odd display behavior in the cygwin bash shell with
> > versions 5.0.2 and 5.0.3 that I have compiled myself, but not with the
> > distributed 5.0.2 cygwin binaries. Below is an example from the g.remove
> > command, but similar problems exhibit themselves in other commands e.g.
> > g.region.  The problem is that part of the left portion of the line 
> most of
> > the lines are missing.
> >
> > 5.0.2 compiled by me (missing left'ly chars):
> >
> >      GRASS:~ > g.remove fsh2b
> >      REMOVE [fsh2b]
> >       raster
> >         ader
> >       category
> >          or
> >        istory
> >
> >          MISSING
> >        MISSING
> >
> > 5.0.2 binary distribution (correct):
> >
> >      GRASS:~ > g.remove msh2b
> >      REMOVE [msh2b]
> >       raster
> >       header
> >       category
> >       color
> >       history
> >       misc
> >       fcell    MISSING
> >       g3dcell  MISSING
> >
> > I have the newest (possibly too new?) cygwin distribution. Most of the 
> text
> > appears correctly, and all of the modules that I have used appear to
> > correctly. Is there a library that is used for this semi-formatted text
> > that may be out of sync on my system? Or another area that I should 
> explore?
>
>The code which produces the above listing is in
>src/general/manage/lib/do_remove.c:
>
>     for (i = 0; i < list[n].nelem; i++)
>     {
>         fprintf (stdout," %-*s ", len, list[n].desc[i]);
>         fflush (stdout);
>
>         switch (G_remove (list[n].element[i], old))
>         {
>         case -1: fprintf (stdout,"COULD NOT REMOVE"); break;
>         case  0: fprintf (stdout,"MISSING"); break;
>         }
>         fprintf (stdout,"\n");
>     }
>
>It appears that fprintf() isn't handling "%-*s" correctly.
>
>I'm not sure how you could get different behaviour for different
>builds of GRASS.
>
>--
>Glynn Clements <glynn.clements at virgin.net>


Richard W. Greenwood, PLS
Greenwood Mapping, Inc.
Rich <at> GreenwoodMap <dot> com
(307) 733-0203
http://www.GreenwoodMap.com