On Feb 6, 2008, at 10:41 AM, Glynn Clements wrote:
Michael Barton wrote:
It looks like the '|' is partly to blame, but not entirely.
If I use the original file with missmatched numbers of fields
between records AND use the '|' separator, I have trouble on my
Mac.
However, if I fix the file so that all records have the same
number of fields (keeping '|' as separator) OR I leave the file
with messed up fields but replace '|' with ',' it works fine.
So it seems more a problem of reading the '|' separator in the
text file in some circumstances than it does having it in the
command string.
Just to make sure: I don't think Helena meant that the '|' as
separator causes any problems. It's the fact that you use
v.in.ascii input=/Users/cmbarton/schools_el_lu.txt
output=schools_lu format=point fs=| skip=0 x=1 y=2 z=0 cat=3
with fs=| where | is unquoted and thus interpreted as pipe command.
Yes,
I understood. But it also looks like it's more complicated. In some
circumstances fs=| works OK (i.e., without quotes) and in other
circumstances it doesn't--suggesting that there also may be a problem
when v.in.ascii reads the | character in the ascii file in some
cases.
If the string is parsed by the shell, it needs to be quoted, otherwise
it doesn't.
Given these tests and what Glynn said (subsequent post), it seems
safest to always quote or escape the | character in v.in.ascii. In
this regard, is there a problem with making the default separator for
the g.parser section of v.in.ascii "|" instead of the current | ?
Yes. That would cause the quotes to be treated as part of the argument
to the fs= option.
I don't understand. Helena suggested that I put quotes around "|",
which I did and which worked--from the GUI. So why not make this the
default
Seems like this would avoid problems when v.in.ascii is run in the
GUI (i.e., instead of having to change the default entry in the
separator field in each case).
There shouldn't be any need for quotes when using the GUI. The GUI
should not be using the shell at all.
This is where it seems to be needed nonetheless. If I run from the
GUI and don't use quotes (and the file structure is bad), it crashes
TclTk. If I run from the command line, it's not running in TclTk and
so TclTk doesn't crash.
As an aside, the | character seems like an odd default separator for
data fields in GRASS. I suppose it's a holdover from the ancient
past. But the fact that this is also has meaning as a pipe seems to
make it a risky separator in general. What about switching this to
something else in GRASS 7?
There's only thing that's "risky" about using "|" is that certain bugs
in code which executes commands will show up rather than getting
overlooked.
If such bugs exist, they should be fixed, rather than having
individual cases worked around.
OK. But I don't understand what needs to be fixed here (though I'd be
happy to have whatever needs to be fixed, fixed). I'm hearing quote
the | character and don't quote the | character. So I'm confused.
Michael
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
