On 05/02/08 17:17, Michael Barton wrote:
On Feb 5, 2008, at 8:48 AM, Moritz Lennert wrote:
I would rather guess that depending on how the command line was
formulated, i.e. where the fs=| is placed, the command runs correctly
with the default values (i.e. '|' as seperator) or doesn't.
Moritz Lennert wrote:
Thanks, the problem has been fixed by installing the gcc-g++ package.
I then compiled with make and got the errors below.
Any idea of what to do in order to get rid of these errors?
All these, except for the i.attcor are known and either 'won't fix' or
at least
Thanks Moritz.
I see now that it is even more complicated than I thought. A
different issue on Windows than on a Mac. The good news is that it
seems to work OK with a good file.
Michael
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of
Markus Neteler wrote:
http://trac.osgeo.org/grass/changeset/30007
...
+ # strangely counts as 1
+ NAMELEN=`echo $newcol | wc -c | awk '{print $1}'`
+ if [ $NAMELEN -gt 11 ] ; then
the extra char is due to the newline:
$ echo | wc -c
1
$ echo -n | wc -c
0
For v.db.renamecol + SQLite
Hi,
g.mapset calls D_erase(), should it?
Obviously the display will be stale after changing the mapset, but for me
a typical use is to drop into the PERMANENT mapset for a minute to adjust
something (say g.region -s or g.setproj), then back to my normal session.
any thoughts? Should g.mapset be
Hamish [EMAIL PROTECTED] writes:
Hi, g.mapset calls D_erase(), should it?
My opinion is that it shouldn't.
I'd say that to ease both the maintenance and learning of GRASS
the modules should have as less side effects as possible.
Obviously the display will be stale
On Feb 8, 2008 12:06 AM, Hamish [EMAIL PROTECTED] wrote:
Markus Neteler wrote:
http://trac.osgeo.org/grass/changeset/30007
...
+ # strangely counts as 1
+ NAMELEN=`echo $newcol | wc -c | awk '{print $1}'`
+ if [ $NAMELEN -gt 11 ] ; then
the extra char is due to the newline:
$
