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