Tue, Feb 15 2005
06:39:26
|
|
Request created by hbowman
|
|
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?)
|
|
Tue, Mar 1 2005
10:27:21
|
|
Final Priority changed to 30 by pcavallini
|
|
Mon, Oct 17 2005
10:30:56
|
|
Comments added by hbowman
|
|
done with new G_getl2() fn by Radim.
check to see that both points mode and standard mode have been done before
closing this bug. I think I only updated points mode. (?)
Hamish
|
|
Wed, Apr 26 2006
07:38:18
|
|
Status changed to resolved by hbowman
|
|
Wed, Apr 26 2006
07:38:18
|
|
Comments added by hbowman
|
|
All done for both modes.
Hamish
|
|