Opened 7 years ago

Closed 3 years ago

#1683 closed defect (fixed)

error message v.db.addcol

Reported by: jradinger Owned by: hamish
Priority: major Milestone: 6.4.6
Component: Shell Scripts Version: svn-develbranch6
Keywords: v.db.addcol Cc: grass-dev@…
CPU: Unspecified Platform: All

Description (last modified by neteler)

When trying to add a new column (v.db.addcol map=basins@test columns=area DOUBLE) following error message is produced. Anyway the column is created and there seems no problem with the database table. Just the error message:

/Applications/GRASS-6.5.app/Contents/MacOS/scripts/v.db.addc
ol: line 80: Radinger/Library/GRASS/6.5/Modules/bin=/Library
/GRASS/6.5/Modules/bin:/Users/Johannes:/Users/Johannes
Radinger/Documents/GRASS-GIS/Scripts: No such file or
directory
/Applications/GRASS-6.5.app/Contents/MacOS/scripts/v.db.addc
ol: line 80: Radinger/Documents/GRASS-
GIS/Scripts=/Users/Johannes Radinger/Desktop: No such file
or directory

Change History (20)

comment:1 Changed 7 years ago by neteler

Description: modified (diff)

comment:2 Changed 7 years ago by neteler

For shell debugging, please change the first line of /Applications/GRASS-6.5.app/Contents/MacOS/scripts/v.db.addcol from

#!/bin/sh

to

#!/bin/sh -x

and run it again. Then post the relevant error part here, thanks.

comment:3 Changed 7 years ago by JRadinger

Here the shell output after running v.db.addcol in shell with changed first line:

GRASS 6.5.svn (spearfish60):~ > v.db.addcol map=streams@test columns="testcol DOUBLE"
+ '[' -z /Applications/GRASS-6.5.app/Contents/MacOS ']'
+ '[' map=streams@test '!=' @ARGS_PARSED@ ']'
++ basename /Applications/GRASS-6.5.app/Contents/MacOS/scripts/v.db.addcol
+ CMDLINE=v.db.addcol
+ for arg in '"$@"'
+ CMDLINE='v.db.addcol "map=streams@test"'
+ for arg in '"$@"'
+ CMDLINE='v.db.addcol "map=streams@test" "columns=testcol DOUBLE"'
+ export CMDLINE
+ exec g.parser /Applications/GRASS-6.5.app/Contents/MacOS/scripts/v.db.addcol map=streams@test 'columns=testcol DOUBLE'
+ '[' -z /Applications/GRASS-6.5.app/Contents/MacOS ']'
+ '[' @ARGS_PARSED@ '!=' @ARGS_PARSED@ ']'
++ basename /Applications/GRASS-6.5.app/Contents/MacOS/scripts/v.db.addcol
+ PROG=v.db.addcol
++ which awk
+ '[' '!' -x /usr/bin/awk ']'
+ unset LC_ALL
+ LC_NUMERIC=C
+ export LC_NUMERIC
++ g.gisenv
+ eval 'GISDBASE='\''/Users/Johannes' 'Radinger/Documents/GRASS-GIS'\'';' 'LOCATION_NAME='\''spearfish60'\'';' 'MAPSET='\''test'\'';' 'ADDON_PATH='\''/Users/Johannes' Radinger/Library/GRASS/6.5/Modules/bin:/Library/GRASS/6.5/Modules/bin:/Users/Johannes 'Radinger/Library/GRASS/6.5/Modules/bin:/Library/GRASS/6.5/Modules/bin:/Users/Johannes'\'';' 'Radinger/Library/GRASS/6.5/Modules/bin='\''/Library/GRASS/6.5/Modules/bin:/Users/Johannes:/Users/Johannes' 'Radinger/Documents/GRASS-GIS/Scripts'\'';' 'Radinger/Documents/GRASS-GIS/Scripts='\''/Users/Johannes' 'Radinger/Desktop'\'';' 'MONITOR='\''x7'\'';' 'GRASS_GUI='\''wxpython'\'';'
++ GISDBASE='/Users/Johannes Radinger/Documents/GRASS-GIS'
++ LOCATION_NAME=spearfish60
++ MAPSET=test
++ ADDON_PATH='/Users/Johannes Radinger/Library/GRASS/6.5/Modules/bin:/Library/GRASS/6.5/Modules/bin:/Users/Johannes Radinger/Library/GRASS/6.5/Modules/bin:/Library/GRASS/6.5/Modules/bin:/Users/Johannes'
++ 'Radinger/Library/GRASS/6.5/Modules/bin=/Library/GRASS/6.5/Modules/bin:/Users/Johannes:/Users/Johannes Radinger/Documents/GRASS-GIS/Scripts'
/Applications/GRASS-6.5.app/Contents/MacOS/scripts/v.db.addcol: line 80: Radinger/Library/GRASS/6.5/Modules/bin=/Library/GRASS/6.5/Modules/bin:/Users/Johannes:/Users/Johannes Radinger/Documents/GRASS-GIS/Scripts: No such file or directory
++ 'Radinger/Documents/GRASS-GIS/Scripts=/Users/Johannes Radinger/Desktop'
/Applications/GRASS-6.5.app/Contents/MacOS/scripts/v.db.addcol: line 80: Radinger/Documents/GRASS-GIS/Scripts=/Users/Johannes Radinger/Desktop: No such file or directory
++ MONITOR=x7
++ GRASS_GUI=wxpython
+ : /Applications/GRASS-6.5.app/Contents/MacOS /Users/Johannes Radinger/Documents/GRASS-GIS spearfish60 test
++ g.findfile element=vector file=streams@test mapset=test
+ eval 'name='\''streams@test'\''' 'mapset='\''test'\''' 'fullname='\''streams@test'\''' 'file='\''/Users/Johannes' 'Radinger/Documents/GRASS-GIS/spearfish60/test/vector/streams'\'''
++ name=streams@test
++ mapset=test
++ fullname=streams@test
++ file='/Users/Johannes Radinger/Documents/GRASS-GIS/spearfish60/test/vector/streams'
+ '[' '!' '/Users/Johannes Radinger/Documents/GRASS-GIS/spearfish60/test/vector/streams' ']'
++ v.db.connect streams@test -gl layer=1 'fs=|'
++ cut -f2 '-d|'
+ table=streams
+ '[' -z streams ']'
++ v.db.connect streams@test -gl 'fs=|' layer=1
++ cut -f4 '-d|'
+ database='/Users/Johannes Radinger/Documents/GRASS-GIS/spearfish60/test/dbf/'
++ v.db.connect streams@test -gl 'fs=|' layer=1
++ cut -f5 '-d|'
+ driver=dbf
++ echo 'testcol DOUBLE'
++ awk -F, '{print NF}'
+ colnum=1
+ n=1
+ '[' 1 -le 1 ']'
++ echo 'testcol DOUBLE'
++ cut -d, -f1
+ col='testcol DOUBLE'
+ '[' -z 'testcol DOUBLE' ']'
+ db.execute 'database=/Users/Johannes Radinger/Documents/GRASS-GIS/spearfish60/test/dbf/' driver=dbf
+ echo 'ALTER TABLE streams ADD COLUMN testcol DOUBLE'
+ '[' 0 -eq 1 ']'
++ expr 1 + 1
+ n=2
+ '[' 2 -le 1 ']'
+ v.support streams@test 'cmdhist=v.db.addcol "map=streams@test" "columns=testcol DOUBLE"'
+ exit 0

comment:4 in reply to:  3 Changed 7 years ago by neteler

Milestone: 6.5.06.4.3
Platform: MacOSXAll
Priority: normalmajor

The problem is the white space in the path not handled properly:

...
+ eval 'GISDBASE='\''/Users/Johannes' 'Radinger/Documents/GRASS-GIS'\'';' 'LOCATION_NAME='\''spearfish60'\'';' 'MAPSET='\''test'\'';' 'ADDON_PATH='\''/Users/Johannes' Radinger/Library/GRASS/6.5/Modules/bin:/Library/GRASS/6.5/Modules/bin:/Users/Johannes 'Radinger/Library/GRASS/6.5/Modules/bin:/Library/GRASS/6.5/Modules/bin:/Users/Johannes'\'';' 'Radinger/Library/GRASS/6.5/Modules/bin='\''/Library/GRASS/6.5/Modules/bin:/Users/Johannes:/Users/Johannes' 'Radinger/Documents/GRASS-GIS/Scripts'\'';' 'Radinger/Documents/GRASS-GIS/Scripts='\''/Users/Johannes' 'Radinger/Desktop'\'';' 'MONITOR='\''x7'\'';' 'GRASS_GUI='\''wxpython'\'';'
++ GISDBASE='/Users/Johannes Radinger/Documents/GRASS-GIS'
++ LOCATION_NAME=spearfish60
++ MAPSET=test
++ ADDON_PATH='/Users/Johannes Radinger/Library/GRASS/6.5/Modules/bin:/Library/GRASS/6.5/Modules/bin:/Users/Johannes Radinger/Library/GRASS/6.5/Modules/bin:/Library/GRASS/6.5/Modules/bin:/Users/Johannes'
++ 'Radinger/Library/GRASS/6.5/Modules/bin=/Library/GRASS/6.5/Modules/bin:/Users/Johannes:/Users/Johannes Radinger/Documents/GRASS-GIS/Scripts'
/Applications/GRASS-6.5.app/Contents/MacOS/scripts/v.db.addcol: line 80: Radinger/Library/GRASS/6.5/Modules/bin=/Library/GRASS/6.5/Modules/bin:/Users/Johannes:/Users/Johannes Radinger/Documents/GRASS-GIS/Scripts: No such file or directory
++ 'Radinger/Documents/GRASS-GIS/Scripts=/Users/Johannes Radinger/Desktop'
/Applications/GRASS-6.5.app/Contents/MacOS/scripts/v.db.addcol: line 80: Radinger/Documents/GRASS-GIS/Scripts=/Users/Johannes Radinger/Desktop: No such file or directory
++ MONITOR=x7
...

--> ADDON_PATH is broken into two lines.

comment:5 Changed 7 years ago by hamish

Component: DatabaseShell Scripts
Keywords: v.db.addcol added; v.add.col removed

The immediate culprit is eval g.gisenv,

The underlying fix is to not store the addon path as a GRASS variable, store it as a shell environment variable -- and only a shell variable -- instead.

Remove it from the g.gisenv list with:

g.gisenv set="ADDON_PATH="

then v.db.addcol should be happy.

Trying to make it both a shell environment variable and a grass variable is well intentioned, but blurring definitions so that things can be set and read independently in multiple places using the same namespace is ultimately going to create more problems than it solves. The main question I think is if we need some other place besides .grass.bashrc to store this sort of thing, to be sourced by the grass startup script. ? (currently for grass6 it needs to be set in ~/.bashrc since .grass.bashrc is sourced later in the startup script.

The GUI can modify its own running environment on the fly with os.environ(); command line users who want to modify their environment generally can, and indeed want to, take care of themselves.

cheers, Hamish

comment:6 Changed 7 years ago by hamish

n.b. the eval g.gisenv will still be problematic if the GISDBASE path contains a space. In this case just the MAPSET name is needed, so eval g.gisenv MAPSET avoids trouble, but quoting by g.gisenv is something we should probably discuss.

(nonetheless, having GRASS_ADDON_PATH enviro var and ADDON_PATH grass var is unfortunate)

Hamish

comment:7 Changed 7 years ago by hamish

devbr6/scripts$ svngrep -r g.gisenv * | grep eval | cut -f1 -d: | uniq | wc -l
37

v.db.addcol restricted to just eval'ing MAPSET in devbr6 r52299, but many still to audit. :-(

Hamish

comment:8 in reply to:  5 Changed 7 years ago by neteler

Replying to hamish:

The immediate culprit is eval g.gisenv,

The underlying fix is to not store the addon path as a GRASS variable, store it as a shell environment variable -- and only a shell variable -- instead.

Remove it from the g.gisenv list with:

g.gisenv set="ADDON_PATH="

then v.db.addcol should be happy.

Backported to 6.4.svn, too.

comment:9 Changed 7 years ago by jradinger

I tried again with the first example (streams@test). No problems occured. Anyway another mapset still produces error messages:

(Tue Aug 14 12:46:01 2012)                                                      
v.db.addcol map=sender_point@FIDIMO_Cele columns=testcol DOUBLE                 
/usr/local/grass-6.5.svn/scripts/v.db.addcol: 1: eval:
FIDIMO_Cele: not found
(Tue Aug 14 12:46:02 2012) Command finished (1 sec)

And here the extended output:

(Tue Aug 14 12:48:12 2012)                                                      
v.db.addcol map=sender_point@FIDIMO_Cele columns=testcol DOUBLE                 
+ [ -z /usr/local/grass-6.5.svn ]
+ [ map=sender_point@FIDIMO_Cele != @ARGS_PARSED@ ]
+ basename /usr/local/grass-6.5.svn/scripts/v.db.addcol
+ CMDLINE=v.db.addcol
+ CMDLINE=v.db.addcol "map=sender_point@FIDIMO_Cele"
+ CMDLINE=v.db.addcol "map=sender_point@FIDIMO_Cele"
"columns=testcol DOUBLE"
+ export CMDLINE
+ exec g.parser /usr/local/grass-6.5.svn/scripts/v.db.addcol
map=sender_point@FIDIMO_Cele columns=testcol DOUBLE
+ [ -z /usr/local/grass-6.5.svn ]
+ [ @ARGS_PARSED@ != @ARGS_PARSED@ ]
+ basename /usr/local/grass-6.5.svn/scripts/v.db.addcol
+ PROG=v.db.addcol
+ which awk
+ [ ! -x /usr/bin/awk ]
+ unset LC_ALL
+ LC_NUMERIC=C
+ export LC_NUMERIC
+ g.gisenv get=MAPSET
+ eval FIDIMO_Cele
+ FIDIMO_Cele
/usr/local/grass-6.5.svn/scripts/v.db.addcol: 1: eval:
FIDIMO_Cele: not found
+ g.findfile element=vector file=sender_point@FIDIMO_Cele
mapset=
+ eval name='sender_point@FIDIMO_Cele' mapset='FIDIMO_Cele'
fullname='sender_point@FIDIMO_Cele' file='/home/radinger/Doc
uments/GRASS_locations/Cele_location/FIDIMO_Cele/vector/send
er_point'
+ name=sender_point@FIDIMO_Cele mapset=FIDIMO_Cele
fullname=sender_point@FIDIMO_Cele file=/home/radinger/Docume
nts/GRASS_locations/Cele_location/FIDIMO_Cele/vector/sender_
point
+ [ ! /home/radinger/Documents/GRASS_locations/Cele_location
/FIDIMO_Cele/vector/sender_point ]
+ v.db.connect sender_point@FIDIMO_Cele -gl layer=1 fs=|
+ cut -f2 -d|
+ table=sender_point
+ [ -z sender_point ]
+ cut -f4 -d|
+ v.db.connect sender_point@FIDIMO_Cele -gl fs=| layer=1
+ database=/home/radinger/Documents/GRASS_locations/Cele_loc
ation/FIDIMO_Cele/sqlite.db
+ cut -f5 -d|
+ v.db.connect sender_point@FIDIMO_Cele -gl fs=| layer=1
+ driver=sqlite
+ awk -F, {print NF}
+ echo testcol DOUBLE
+ colnum=1
+ n=1
+ [ 1 -le 1 ]
+ cut -d, -f1
+ echo testcol DOUBLE
+ col=testcol DOUBLE
+ [ -z testcol DOUBLE ]
+ db.execute database=/home/radinger/Documents/GRASS_locatio
ns/Cele_location/FIDIMO_Cele/sqlite.db driver=sqlite
+ echo ALTER TABLE sender_point ADD COLUMN testcol DOUBLE
+ [ 0 -eq 1 ]
+ expr 1 + 1
+ n=2
+ [ 2 -le 1 ]
+ v.support sender_point@FIDIMO_Cele cmdhist=v.db.addcol
"map=sender_point@FIDIMO_Cele" "columns=testcol DOUBLE"
+ exit 0
(Tue Aug 14 12:48:13 2012) Command finished (1 sec)

So far as I can see there is no whitespace in the mapset. Tested on Ubuntu 12.04 with Grass6-devel r52671. This might be related to ticket #1696.

/johannes

comment:10 Changed 7 years ago by jradinger

Summary: error message v.add.col on MacOSXerror message v.db.addcol

comment:11 Changed 7 years ago by hamish

Cc: grass-dev@… added
Owner: changed from grass-dev@… to hamish
Status: newassigned

(see comment:5)

what does g.gisenv by itself on the command line show?

does you mapset have a space in it? (AFAIU you should have gotten an error when you tried)

Hamish

comment:12 Changed 7 years ago by jradinger

sorry for responding so late.

today I tried example again and found out that the error messages are related a messy gisenv. Here first the errors from v.db.addcol

v.db.addcol map="test@FIDIMO_Cele" columns="testcol DOUBLE"
/usr/local/grass-6.5.svn/scripts/v.db.addcol: 1: eval: adinger/U_Radinger/05_GRASS/GR=/home/radinger/U_Radinger/05_GRASS/GRASS_Scripts: not found
/usr/local/grass-6.5.svn/scripts/v.db.addcol: 1: eval: adinger/05_GRASS/GRASS_Scripts=/home/radinger/U_Radinger/05_GRASS/FIDIMO/FIDIMO_Script/fidimo for grass 6.x/r.fidimo: not found
/usr/local/grass-6.5.svn/scripts/v.db.addcol: 1: eval: /r.rdfilter=/home/radinger/U_Radinger/05_GRASS/FIDIMO/FIDIMO_Script/fidimo for grass 6.x/r.fidimo: not found
GRASS 6.5.svn (Cele_location):~ >

So I also checked the output of g.gisenv from the command line which seems somehow wrong. I looks like the output for GRASS_SCRIPTS is "chopped up" and messy, and I don't know how this could happen.

GRASS 6.5.svn (Cele_location):~ > g.gisenv
GISDBASE=/home/radinger/Documents/GRASS_locations
LOCATION_NAME=Cele_location
MAPSET=FIDIMO_Cele
ADDON_PATH=/home/radinger/.grass6/addons:/home/radinger/.grass6/addons:/home/radinger/.grass6/addons:/home/radinger/.grass6/addons:/home/radinger/.grass6/addons:/home/radinger/.grass6/addons:/home/r
adinger/U_Radinger/05_GRASS/GR=/home/radinger/U_Radinger/05_GRASS/GRASS_Scripts
ASS_Scripts=/home/radinger/U_R:/home/radinger/U_Radinger/05_GRASS/GRASS_Scripts/FIDIMO_testbed
adinger/05_GRASS/GRASS_Scripts=/home/radinger/U_Radinger/05_GRASS/FIDIMO/FIDIMO_Script/fidimo for grass 6.x/r.fidimo
/r.rdfilter=/home/radinger/U_Radinger/05_GRASS/FIDIMO/FIDIMO_Script/fidimo for grass 6.x/r.fidimo
GRASS_GUI=wxpython
GRASS 6.5.svn (Cele_location):~ > 

How can I clean up my gisenv as I think that might solve the problem? Whats the best way? My ADDON_PATH is extremely long and repeatedly the same. Furthermore it seems there is a line break in gisenv dividing "r" and "adinger...", which is causing the problem above.

I still don't know how this could happen as I never touched the gisenv deliberately.

/j

comment:13 Changed 7 years ago by jradinger

And no, my mapset generally don't have any spaces in it, just to avoid such problems

comment:14 in reply to:  12 Changed 7 years ago by mmetz

Replying to jradinger:

How can I clean up my gisenv as I think that might solve the problem? Whats the best way? My ADDON_PATH is extremely long and repeatedly the same. Furthermore it seems there is a line break in gisenv dividing "r" and "adinger...", which is causing the problem above.

I still don't know how this could happen as I never touched the gisenv deliberately.

The repetitions in ADDON_PATH could be caused by a bug in g.extension. You could try to manually edit ~/.grass7/rc.

Markus M

comment:15 in reply to:  12 Changed 7 years ago by hamish

Replying to jradinger:

sorry for responding so late.

ditto, better a late response than none :)

How can I clean up my gisenv as I think that might solve the problem? Whats the best way? My ADDON_PATH is extremely long and repeatedly the same. Furthermore it seems there is a line break in gisenv dividing "r" and "adinger...", which is causing the problem above.

see comment:5.

MarkusM wrote:

You could try to manually edit ~/.grass7/rc.

In GRASS 6 the file is ~/.grassrc6, and you should not be in a GRASS session when you edit it.

I have had another attempt at making v.db.addcol more robust to external g.gisenv problems in r55162,3. This report should stay open until the other ~36 scripts that use eval g.gisenv but only really need one variable from it have been checked/fixed. Spaces and other fun chars in GISDBASE will make eval unhappy.

Hamish

comment:16 Changed 7 years ago by hamish

Hi,

scripts in devbr6 now updated with r55194:55226, but need testing before backport to the stable branch.

AFAICT the only ones which will actually trigger run-time processing errors (instead of just the occasional harmless message) on WinGrass w/ spaces in GISDBASE, are:

  • r.pack/unpack (already backported)
  • r.in.srtm
  • db.droptable
  • d.rast.leg (bug? try erode.index@spearfish)
  • r.in.wms
  • i.image.mosaic
  • v.in.garmin (doesn't need to be fixed for wingrass as dep req's UNIX)

so those should be tested & then backported for 6.4.3.

the rest can wait until after the freeze and go in for 6.4.4.

Hamish

comment:17 Changed 7 years ago by hamish

Milestone: 6.4.36.4.4

non-harmless cases listed in comment:16 backported to relbr64 in r55725. testing still welcomed.

Hamish

comment:18 in reply to:  17 ; Changed 6 years ago by neteler

Replying to hamish:

scripts in devbr6 now updated with r55194:55226, but need testing before backport to the stable branch.

For the record: Apparently are all r55194:55226 changes present in relbr6, so they will go into GRASS 6.4.4, nice.

Replying to hamish:

non-harmless cases listed in comment:16 backported to relbr64 in r55725. testing still welcomed.

No issues reported so far.

comment:19 Changed 4 years ago by neteler

Milestone: 6.4.46.4.6

Can this be closed?

comment:20 in reply to:  18 Changed 3 years ago by mlennert

Resolution: fixed
Status: assignedclosed

Replying to neteler:

Replying to hamish:

scripts in devbr6 now updated with r55194:55226, but need testing before backport to the stable branch.

For the record: Apparently are all r55194:55226 changes present in relbr6, so they will go into GRASS 6.4.4, nice.

Replying to hamish:

non-harmless cases listed in comment:16 backported to relbr64 in r55725. testing still welcomed.

No issues reported so far.

Still none reported, so closing.

Note: See TracTickets for help on using tickets.