[GRASS5] [bug #2641] (grass) [5.7] v.in.ascii support for Mac OS9 and DOS newlines

this bug's URL: http://intevation.de/rt/webrt?serial_num=2641
-------------------------------------------------------------------------

Subject: [5.7] v.in.ascii support for Mac OS9 and DOS newlines

Platform: GNU/Linux/i386
grass obtained from: Mirror of Trento site
grass binary for platform: Compiled from Sources
GRASS Version: 5.7 cvs sept 2004

It would be nice if 5.7's v.in.ascii input from stdin supported Mac OS9 and DOS newlines as well as UNIX ones. Just tried using it with a tab delimited text file created in Win2k Excel on a OSX installation of GRASS; MS IE on OSX saved the attachment as a Mac OS9 text file (argh), Safari saved it in original DOS format... the conversion is not exactly something I could explain to the student who only knew about Macs...

complication I had implementing this in 5.3's s.in.ascii: fgetl() doesn't stop on \r's (Mac OS/9); I think v.in.ascii figures out input line length and uses fgets(,maxlength), so this might not be an issue here.

For DOS files you need to strip the \r from the end of the line if it exists otherwise it shows up in the last (text) field.

Hamish

-------------------------------------------- Managed by Request Tracker

Request Tracker wrote:

this bug's URL: http://intevation.de/rt/webrt?serial_num=2641
-------------------------------------------------------------------------

Subject: [5.7] v.in.ascii support for Mac OS9 and DOS newlines

Platform: GNU/Linux/i386
grass obtained from: Mirror of Trento site
grass binary for platform: Compiled from Sources
GRASS Version: 5.7 cvs sept 2004

It would be nice if 5.7's v.in.ascii input from stdin supported Mac
OS9 and DOS newlines as well as UNIX ones. Just tried using it with a
tab delimited text file created in Win2k Excel on a OSX installation
of GRASS; MS IE on OSX saved the attachment as a Mac OS9 text file
(argh), Safari saved it in original DOS format... the conversion is
not exactly something I could explain to the student who only knew
about Macs...

complication I had implementing this in 5.3's s.in.ascii: fgetl()
doesn't stop on \r's (Mac OS/9);

What is fgetl()? Or did you mean G_getl()?

I think v.in.ascii figures out input
line length and uses fgets(,maxlength), so this might not be an issue
here.

fgets() also stops on \n (G_getl() just calls fgets() and removes the
terminating NUL), so the same issue applies there.

For DOS files you need to strip the \r from the end of the line if it
exists otherwise it shows up in the last (text) field.

Yep.

The only thing which will work with Mac text files is avoiding the use
of fgets() altogether. There are currently around 250 files which use
fgets(), so this isn't a trivial change.

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

[reposted from Bug tracker]

> complication I had implementing this in 5.3's s.in.ascii: fgetl()
> doesn't stop on \r's (Mac OS/9);

What is fgetl()? Or did you mean G_getl()?

oh sorry, I'm confusing my Matlab and C commands.
(in Matlab fgetl() is fgets() but strips off the \n while fgets()
doesn't)

The only thing which will work with Mac text files is avoiding the use
of fgets() altogether. There are currently around 250 files which use
fgets(), so this isn't a trivial change.

which is why for s.in.ascii I had it G_fatal_error() if it found a Mac
OS9 file..

OS9 format is heading into the past now, so I don't think changing
G_getl() as a start is worth it.

Hamish