Hello,
In order to make zoom and pan work for me from the GIS manager, I had to
change lines 419 and 427 of d.m.tcl to use the "execute" function instead
of the "term" function. With the latter, I just get an additional xterm
that flashes up very briefly and then closes without anything happening.
This is with yesterday's CVS version of 5.7 and 5.3 on Debian
testing/unstable.
Moritz
On Wed, September 22, 2004 14:55, Moritz Lennert said:
Hello,
In order to make zoom and pan work for me from the GIS manager, I had to
change lines 419 and 427 of d.m.tcl to use the "execute" function instead
of the "term" function. With the latter, I just get an additional xterm
that flashes up very briefly and then closes without anything happening.This is with yesterday's CVS version of 5.7 and 5.3 on Debian
testing/unstable.
Replying to myself: the same is true for the query functions, d.what.vect
and d.what.rast for which I had to change the call from
"term" to "run" respectively in vector.tcl and raster.tcl.
Moritz
Moritz,
I happened to run into the behavior of the xterm opening and closing
immediately last night. It happened when I had a raster layer added in the
GIS Manager, but had forgotten to enter the name of an existing raster file
in the name box. I don't know something along this line is causing your
problem or whether it is another issue related to your build or OS. The
reason for using the term procedure is to open a separate xterm in which to
better see the mouse commands and command output.
The procedure simply calls
exec xterm -e [COMMAND NAME] [COMMAND ARGUMENTS] &
Try to use this format instead of the run procedure and see what happens. It
may also be an issue that none of the commands that you mention actually
have arguments except for pan (d.zoom -p).
Michael
On 9/22/04 1:24 PM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:
On Wed, September 22, 2004 14:55, Moritz Lennert said:
Hello,
In order to make zoom and pan work for me from the GIS manager, I had to
change lines 419 and 427 of d.m.tcl to use the "execute" function instead
of the "term" function. With the latter, I just get an additional xterm
that flashes up very briefly and then closes without anything happening.This is with yesterday's CVS version of 5.7 and 5.3 on Debian
testing/unstable.Replying to myself: the same is true for the query functions, d.what.vect
and d.what.rast for which I had to change the call from"term" to "run" respectively in vector.tcl and raster.tcl.
Moritz
______________________________
Michael Barton, Professor & Curator
School of Human Diversity and Social Change
Arizona State University
Tempe, AZ 85287-2402
USA
voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
Moritz Lennert wrote:
> In order to make zoom and pan work for me from the GIS manager, I had to
> change lines 419 and 427 of d.m.tcl to use the "execute" function instead
> of the "term" function. With the latter, I just get an additional xterm
> that flashes up very briefly and then closes without anything happening.
>
> This is with yesterday's CVS version of 5.7 and 5.3 on Debian
> testing/unstable.Replying to myself: the same is true for the query functions, d.what.vect
and d.what.rast for which I had to change the call from
"term" to "run" respectively in vector.tcl and raster.tcl.
Note that the term and run procedures expect any command-line
arguments to be passed as additional arguments, e.g.:
term d.zoom -p
Using:
term "d.zoom -p"
won't work.
Similarly, the execute procedure requires a command with no arguments,
as it always passes the --ui switch.
--
Glynn Clements <glynn.clements@virgin.net>
Moritz,
Look in $GISBASE/etc/d.m/d.m.tcl for the following lines
# zoom
proc Dm::zoom { } {
set cmd "d.zoom"
term $cmd
}
# pan
proc Dm::pan { } {
set cmd "d.zoom -p"
term $cmd
}
***** Try writing them as ...
# zoom
proc Dm::zoom { } {
term d.zoom
}
# pan
proc Dm::pan { } {
term d.zoom -p
}
See if this fixes the problem. If so, I can easily make a generic change to
all the buttons as they all use this format.
Michael
On 9/22/04 2:46 PM, "Glynn Clements" <glynn.clements@virgin.net> wrote:
Moritz Lennert wrote:
In order to make zoom and pan work for me from the GIS manager, I had to
change lines 419 and 427 of d.m.tcl to use the "execute" function instead
of the "term" function. With the latter, I just get an additional xterm
that flashes up very briefly and then closes without anything happening.This is with yesterday's CVS version of 5.7 and 5.3 on Debian
testing/unstable.Replying to myself: the same is true for the query functions, d.what.vect
and d.what.rast for which I had to change the call from
"term" to "run" respectively in vector.tcl and raster.tcl.Note that the term and run procedures expect any command-line
arguments to be passed as additional arguments, e.g.:term d.zoom -p
Using:
term "d.zoom -p"
won't work.
Similarly, the execute procedure requires a command with no arguments,
as it always passes the --ui switch.
______________________________
Michael Barton, Professor & Curator
School of Human Diversity and Social Change
Arizona State University
Tempe, AZ 85287-2402
USA
voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
On Wed, September 22, 2004 23:46, Glynn Clements said:
Moritz Lennert wrote:
> In order to make zoom and pan work for me from the GIS manager, I had
to
> change lines 419 and 427 of d.m.tcl to use the "execute" function
instead
> of the "term" function. With the latter, I just get an additional
xterm
> that flashes up very briefly and then closes without anything
happening.
>
> This is with yesterday's CVS version of 5.7 and 5.3 on Debian
> testing/unstable.Replying to myself: the same is true for the query functions,
d.what.vect
and d.what.rast for which I had to change the call from
"term" to "run" respectively in vector.tcl and raster.tcl.Note that the term and run procedures expect any command-line
arguments to be passed as additional arguments, e.g.:term d.zoom -p
Using:
term "d.zoom -p"
won't work.
Similarly, the execute procedure requires a command with no arguments,
as it always passes the --ui switch.
It does accept the -p switch though...
Moritz
On Thu, September 23, 2004 0:10, Michael Barton said:
Moritz,
Look in $GISBASE/etc/d.m/d.m.tcl for the following lines
# zoom
proc Dm::zoom { } {set cmd "d.zoom"
term $cmd}
# pan
proc Dm::pan { } {set cmd "d.zoom -p"
term $cmd}
***** Try writing them as ...
# zoom
proc Dm::zoom { } {term d.zoom
}
# pan
proc Dm::pan { } {term d.zoom -p
}
See if this fixes the problem. If so, I can easily make a generic change
to
all the buttons as they all use this format.
No, this doesn't make a difference for me...
When I try to launch 'xterm -e d.zoom' from the GRASS command line, I have
the same problem. When I launch xterm from the GRASS command line I get an
xterm, but when I enter d.zoom in there, I get:
d.zoom: error while loading shared libraries: libgrass_display.so: cannot
open shared object file: No such file or directory
It seems that the new xterm doesn't know about GRASS. Might this be the
problem with the term procedure in tcl as well ?
Moritz
Moritz Lennert wrote:
> See if this fixes the problem. If so, I can easily make a generic change
> to
> all the buttons as they all use this format.No, this doesn't make a difference for me...
When I try to launch 'xterm -e d.zoom' from the GRASS command line, I have
the same problem. When I launch xterm from the GRASS command line I get an
xterm, but when I enter d.zoom in there, I get:d.zoom: error while loading shared libraries: libgrass_display.so: cannot
open shared object file: No such file or directory
This usually occurs because xterm is setuid/setgid. For security
reasons, the loader unsets certain environment variables (e.g.
LD_LIBRARY_PATH) when running setuid/setgid programs.
You need to add the full path for $GISBASE/lib to /etc/ld.so.conf then
run ldconfig. This will allow the GRASS shared libraries to be found
when LD_LIBRARY_PATH is unset.
However, this isn't a solution if you are using multiple versions of
GRASS. Simply adding all of the lib directories won't work. As the
shared libraries aren't versioned, the loader will load the first
matching library which it finds, which won't necessarily be the
correct one.
We need to install a script along the lines of:
#!/bin/sh
LD_LIBRARY_PATH="$GISBASE/lib"
export LD_LIBRARY_PATH
exec "$@"
(except that the exact variable name is platform-specific) and use
that when runing programs via xterm, i.e.:
exec xterm -e $env(GISBASE)/etc/grass-run.sh d.zoom
--
Glynn Clements <glynn.clements@virgin.net>
On Thu, September 23, 2004 13:06, Glynn Clements said:
Moritz Lennert wrote:
> See if this fixes the problem. If so, I can easily make a generic
change
> to
> all the buttons as they all use this format.No, this doesn't make a difference for me...
When I try to launch 'xterm -e d.zoom' from the GRASS command line, I
have
the same problem. When I launch xterm from the GRASS command line I get
an
xterm, but when I enter d.zoom in there, I get:d.zoom: error while loading shared libraries: libgrass_display.so:
cannot
open shared object file: No such file or directoryThis usually occurs because xterm is setuid/setgid. For security
reasons, the loader unsets certain environment variables (e.g.
LD_LIBRARY_PATH) when running setuid/setgid programs.You need to add the full path for $GISBASE/lib to /etc/ld.so.conf then
run ldconfig. This will allow the GRASS shared libraries to be found
when LD_LIBRARY_PATH is unset.
This solves my problem since I am running only 5.7. But I guess below
solution would be more portable if we can find a way of determining the
correct variable name.
However, this isn't a solution if you are using multiple versions of
GRASS. Simply adding all of the lib directories won't work. As the
shared libraries aren't versioned, the loader will load the first
matching library which it finds, which won't necessarily be the
correct one.We need to install a script along the lines of:
#!/bin/sh
LD_LIBRARY_PATH="$GISBASE/lib"
export LD_LIBRARY_PATH
exec "$@"(except that the exact variable name is platform-specific) and use
that when runing programs via xterm, i.e.:exec xterm -e $env(GISBASE)/etc/grass-run.sh d.zoom
Moritz
[Debian/testing: Zoom, Pan, digit, and query buttons don't work in d.m]
> > See if this fixes the problem. If so, I can easily make a generic
> > change to all the buttons as they all use this format.
>
> No, this doesn't make a difference for me...
>
> When I try to launch 'xterm -e d.zoom' from the GRASS command line,
> I have the same problem. When I launch xterm from the GRASS command
> line I get an xterm, but when I enter d.zoom in there, I get:
>
> d.zoom: error while loading shared libraries: libgrass_display.so:
> cannot open shared object file: No such file or directoryThis usually occurs because xterm is setuid/setgid. For security
reasons, the loader unsets certain environment variables (e.g.
LD_LIBRARY_PATH) when running setuid/setgid programs.You need to add the full path for $GISBASE/lib to /etc/ld.so.conf then
run ldconfig. This will allow the GRASS shared libraries to be found
when LD_LIBRARY_PATH is unset.
[that fixes it but isn't a real solution]
mmmn..
$ ls -l `which xterm`
-rwxr-sr-x 1 root utmp 259896 Sep 29 00:10 /usr/bin/X11/xterm*
'adduser $USER utmp' doesn't help. didn't try as root.
from the command line:
xterm -e "ls $LD_LIBRARY_PATH/libgrass_gis* ; g.version ; read"
pops up a window with this output:
/usr/local/src/grass/grass57/dist.i686-pc-linux-gnu/lib/libgrass_gis.so
g.version: error while loading shared libraries: libgrass_gis.so: cannot open shared object file: No such file or directory
so $LD_LIBRARY_PATH survives, ???
$PATH must survive, otherwise it wouldn't have found the
$GISBASE/bin/g.version which called libgrass_gis.so ...
If it were ignoring $LD_LIBRARY_PATH I'd think it would ignore $PATH
as well?
anyone remember if there was a Debconf question about this lately?
--
some possible temporary fixes for display/d.m/d.m.tcl:
d.zoom changing 'term' to 'run' seems to work (text->console)
d.zoom -p changing 'term' to 'run' seems to work (text->console)
'term' would need: set cmd "d.zoom"; set args "-p"; term $cmd $args ??
query ? don't know how to fix
r.digit: changing 'term' to 'run' seems to work (text->console)
comment out $sel with a # (or remove)
[no base map needed; best to open g.mapsets like menu
for vector / raster digitizing if nothing selected??]
Hamish
The advantange of using term instead of run is that it pops up a separate
xterm, that is specific to that command, is uncluttered by GRASS command
line input and output, and goes away when the command is finished. However,
if this doesn't work on some systems, run will do the same thing, but in the
GRASS command line xterm.
I am OK with reverting all these commands back to run, but wonder if there
is some kind of bigger issue to be fixed for which this is the tip of a
digital iceberg?
Michael
On 10/20/04 7:06 AM, "Hamish" <hamish_nospam@yahoo.com> wrote:
--
some possible temporary fixes for display/d.m/d.m.tcl:
d.zoom changing 'term' to 'run' seems to work (text->console)
d.zoom -p changing 'term' to 'run' seems to work (text->console)
'term' would need: set cmd "d.zoom"; set args "-p"; term $cmd $args ??query ? don't know how to fix
r.digit: changing 'term' to 'run' seems to work (text->console)
comment out $sel with a # (or remove)
[no base map needed; best to open g.mapsets like menu
for vector / raster digitizing if nothing selected??]Hamish
______________________________
Michael Barton, Professor of Anthropology
School of Human, Cultural, and Social Change
Arizona State University
Tempe, AZ 85287-2402
USA
voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
On Wed, 20 Oct 2004, Michael Barton wrote:
The advantange of using term instead of run is that it pops up a separate
xterm, that is specific to that command, is uncluttered by GRASS command
line input and output, and goes away when the command is finished. However,
if this doesn't work on some systems, run will do the same thing, but in the
GRASS command line xterm.I am OK with reverting all these commands back to run, but wonder if there
is some kind of bigger issue to be fixed for which this is the tip of a
digital iceberg?
Is this the LD_LIBRARY_PATH issue? This message:
http://grass.itc.it/pipermail/grass5/2004-September/015412.html
explains the issue very well and even gives the solution: create a script
#!/bin/sh
LD_LIBRARY_PATH="$GISBASE/lib"
export LD_LIBRARY_PATH
exec "$@"
This would need to be held in the source tree as a shell script source, then at compile time the Makefile could run a sed command to replace LD_LIBRARY_PATH_VAR with the name of the variable as used on the particular system (DYLD_LIBRARY_PATH for Mac OSX and PATH for Cygwin are the only two different ones I've come across). See the Makefile for lib/init for an example of this.
As Glynn suggested, ${GISBASE}/etc/grass-run.sh would be a good location and name for the short script.
Paul
This seems like a more comprehensive solution to an issue that might crop up
elsewhere.
Michael
On 10/20/04 9:12 AM, "Paul Kelly" <paul-grass@stjohnspoint.co.uk> wrote:
On Wed, 20 Oct 2004, Michael Barton wrote:
The advantange of using term instead of run is that it pops up a separate
xterm, that is specific to that command, is uncluttered by GRASS command
line input and output, and goes away when the command is finished. However,
if this doesn't work on some systems, run will do the same thing, but in the
GRASS command line xterm.I am OK with reverting all these commands back to run, but wonder if there
is some kind of bigger issue to be fixed for which this is the tip of a
digital iceberg?Is this the LD_LIBRARY_PATH issue? This message:
http://grass.itc.it/pipermail/grass5/2004-September/015412.html
explains the issue very well and even gives the solution: create a script
#!/bin/sh
LD_LIBRARY_PATH="$GISBASE/lib"
export LD_LIBRARY_PATH
exec "$@"This would need to be held in the source tree as a shell script source,
then at compile time the Makefile could run a sed command to replace
LD_LIBRARY_PATH_VAR with the name of the variable as used on the
particular system (DYLD_LIBRARY_PATH for Mac OSX and PATH for Cygwin are
the only two different ones I've come across). See the Makefile for
lib/init for an example of this.
As Glynn suggested, ${GISBASE}/etc/grass-run.sh would be a good location
and name for the short script.Paul
______________________________
Michael Barton, Professor of Anthropology
School of Human, Cultural, and Social Change
Arizona State University
Tempe, AZ 85287-2402
USA
voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
Hamish wrote:
> > > See if this fixes the problem. If so, I can easily make a generic
> > > change to all the buttons as they all use this format.
> >
> > No, this doesn't make a difference for me...
> >
> > When I try to launch 'xterm -e d.zoom' from the GRASS command line,
> > I have the same problem. When I launch xterm from the GRASS command
> > line I get an xterm, but when I enter d.zoom in there, I get:
> >
> > d.zoom: error while loading shared libraries: libgrass_display.so:
> > cannot open shared object file: No such file or directory
>
> This usually occurs because xterm is setuid/setgid. For security
> reasons, the loader unsets certain environment variables (e.g.
> LD_LIBRARY_PATH) when running setuid/setgid programs.
>
> You need to add the full path for $GISBASE/lib to /etc/ld.so.conf then
> run ldconfig. This will allow the GRASS shared libraries to be found
> when LD_LIBRARY_PATH is unset.[that fixes it but isn't a real solution]
A better solution is to install a script to re-set LD_LIBRARY_PATH,
e.g.:
#!/bin/sh
if [ -n "$LD_LIBRARY_PATH" ] ; then
LD_LIBRARY_PATH=$GISBASE/lib:$LD_LIBRARY_PATH
else
LD_LIBRARY_PATH=$GISBASE/lib
fi
export LD_LIBRARY_PATH
prog="$1"
shift
exec "$prog" "$@"
then change the "term" function to use it, e.g.:
proc term {cmd args} {
eval exec -- xterm -e $env(GISBASE)/etc/run $cmd $args &
}
The script would have to be dynamically generated to use the correct
variable name, as is currently done for etc/Init.sh.
mmmn..
$ ls -l `which xterm`
-rwxr-sr-x 1 root utmp 259896 Sep 29 00:10 /usr/bin/X11/xterm*
This is setgid, so LD_* will be cleared.
from the command line:
xterm -e "ls $LD_LIBRARY_PATH/libgrass_gis* ; g.version ; read"pops up a window with this output:
/usr/local/src/grass/grass57/dist.i686-pc-linux-gnu/lib/libgrass_gis.so
g.version: error while loading shared libraries: libgrass_gis.so: cannot open shared object file: No such file or directoryso $LD_LIBRARY_PATH survives, ???
No. The expansion is performed by the shell from which xterm is run.
You would need to use e.g.:
xterm -e sh -c 'ls $LD_LIBRARY_PATH/libgrass_gis* ; g.version ; read'
[Note: *single* quotes.]
$PATH must survive, otherwise it wouldn't have found the
$GISBASE/bin/g.version which called libgrass_gis.so ...If it were ignoring $LD_LIBRARY_PATH I'd think it would ignore $PATH
as well?
No. $PATH doesn't have the same security implications.
--
Glynn Clements <glynn.clements@virgin.net>
A better solution is to install a script to re-set LD_LIBRARY_PATH,
e.g.:#!/bin/sh
if [ -n "$LD_LIBRARY_PATH" ] ; then
LD_LIBRARY_PATH=$GISBASE/lib:$LD_LIBRARY_PATH
else
LD_LIBRARY_PATH=$GISBASE/lib
fi
export LD_LIBRARY_PATH
prog="$1"
shift
exec "$prog" "$@"then change the "term" function to use it, e.g.:
proc term {cmd args} {
eval exec -- xterm -e $env(GISBASE)/etc/run $cmd $args &
}The script would have to be dynamically generated to use the correct
variable name, as is currently done for etc/Init.sh.
...
> from the command line:
> xterm -e "ls $LD_LIBRARY_PATH/libgrass_gis* ; g.version ; read"
>
> pops up a window with this output:
> /usr/local/src/grass/grass57/dist.i686-pc-linux-gnu/lib/libgrass_gis.so
> g.version: error while loading shared libraries: libgrass_gis.so: cannot open shared object file: No such file or directory
>
>
> so $LD_LIBRARY_PATH survives, ???No. The expansion is performed by the shell from which xterm is run.
aah, yes.
You would need to use e.g.:
xterm -e sh -c 'ls $LD_LIBRARY_PATH/libgrass_gis* ; g.version ; read'
[Note: *single* quotes.]
That gives:
ls: /libgrass_gis*: No such file or directory
g.version: error while loading shared libraries: libgrass_gis.so: cannot open shared object file: No such file or directory
Other checks show that $PATH and $GISBASE both survive.
So implementing the above script should fix this.
Hamish
Could this somehow be worked into the init.sh script so as to do a tiny bit
to keep multiple file clutter to a minimum? If not I'd suggest to put it in
gui.tcl as a procedure, or barring that in $GISBASE/etc/d.m/script except
that it seems like some people need it for the command line in a few cases
if I understood some of the comments earlier.
Michael
On 10/20/04 6:28 PM, "Hamish" <hamish_nospam@yahoo.com> wrote:
A better solution is to install a script to re-set LD_LIBRARY_PATH,
e.g.:#!/bin/sh
if [ -n "$LD_LIBRARY_PATH" ] ; then
LD_LIBRARY_PATH=$GISBASE/lib:$LD_LIBRARY_PATH
else
LD_LIBRARY_PATH=$GISBASE/lib
fi
export LD_LIBRARY_PATH
prog="$1"
shift
exec "$prog" "$@"then change the "term" function to use it, e.g.:
proc term {cmd args} {
eval exec -- xterm -e $env(GISBASE)/etc/run $cmd $args &
}The script would have to be dynamically generated to use the correct
variable name, as is currently done for etc/Init.sh....
from the command line:
xterm -e "ls $LD_LIBRARY_PATH/libgrass_gis* ; g.version ; read"pops up a window with this output:
/usr/local/src/grass/grass57/dist.i686-pc-linux-gnu/lib/libgrass_gis.so
g.version: error while loading shared libraries: libgrass_gis.so: cannot
open shared object file: No such file or directoryso $LD_LIBRARY_PATH survives, ???
No. The expansion is performed by the shell from which xterm is run.
aah, yes.
You would need to use e.g.:
xterm -e sh -c 'ls $LD_LIBRARY_PATH/libgrass_gis* ; g.version ; read'
[Note: *single* quotes.]
That gives:
ls: /libgrass_gis*: No such file or directory
g.version: error while loading shared libraries: libgrass_gis.so: cannot open
shared object file: No such file or directoryOther checks show that $PATH and $GISBASE both survive.
So implementing the above script should fix this.
Hamish
____________________
C. Michael Barton, Professor of Anthropology
School of Human, Cultural, and Social Change
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA
Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>
Michael Barton wrote:
Could this somehow be worked into the init.sh script so as to do a tiny bit
to keep multiple file clutter to a minimum? If not I'd suggest to put it in
gui.tcl as a procedure, or barring that in $GISBASE/etc/d.m/script except
that it seems like some people need it for the command line in a few cases
if I understood some of the comments earlier.
None of those will work. If a command is run via xterm, and xterm is
setuid or setgid, LD_LIBRARY_PATH will be cleared. Thus, anything
which runs GRASS programs via "xterm -e ..." (i.e. tcltkgrass, d.m)
must arrange for LD_LIBRARY_PATH to be re-set before the actual
program is run.
--
Glynn Clements <glynn.clements@virgin.net>