[GRASS5] [bug #2995] (grass) v.in.ascii: more robust support for Mac OS9 newlines

[Request Tracker]

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

Subject: v.in.ascii: more robust support for Mac OS9 newlines

(points mode)
v.in.ascii will fail when given a Mac OS9 formatted input file.
i.e. with '\r' (^M) characters to signal end-of-line.

G_getl() by way of fgets() doesn't stop at a '\r'.


currently v.in.ascii tries to detect these and spits out an informative error.
e.g. a file created in Excel on a PC & emailed to self on a web email acc't
then downloaded with MS Exporer on Mac would make a Mac OS9 text file. (Safari
leaves the file alone or makes it into a UNIX textfile AFAICT).

However this doesn't always work, it relies on the file ending in a '\r'
newline. 'Excel for OSX' .csv files save as a OS9 filetype without this
newline. As this is a major way of getting text input into GRASS on Macs we
have a problem. argh.

The user can install bbedit or nedit[*] and resave the file, or even use 'tr',
but it doesn't exactly sell them on GRASS.

[*] now with Mac binaries!


best solution: update G_getl() to see '\r' as a newline.
passable solution: fix Mac OS9 finding logic in v.in.ascii
 (does the "file" unix program exist everywhere &/or exist in a form callable
from all C compilers?)


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