Hi,
Debian folks are unhappy with the hardcoded 'xterm' in
many places and suggest to replace it with a wrapper script so
that they have to change it in a single place later.
Should we invent a 'grass-xterm' script (in $ETC?) for
that? What would be the needed content (thinking portability)?
Markus
Markus Neteler wrote:
Debian folks are unhappy with the hardcoded 'xterm' in
many places and suggest to replace it with a wrapper script so
that they have to change it in a single place later.Should we invent a 'grass-xterm' script (in $ETC?) for
that? What would be the needed content (thinking portability)?
That's one option; another is an environment variable, GRASS_XTERM. If
a wrapper script is used, it should check $GRASS_XTERM before falling
back to x-terminal-emulator or xterm.
In the longer term, we need to make more progress on eliminating the
need for a terminal. The inability to access certain functionality
without a (curses-compatible) terminal should be considered a bug.
--
Glynn Clements <glynn@gclements.plus.com>
On Sun, Aug 27, 2006 at 12:52:35PM +0100, Glynn Clements wrote:
Markus Neteler wrote:
> Debian folks are unhappy with the hardcoded 'xterm' in
> many places and suggest to replace it with a wrapper script so
> that they have to change it in a single place later.
>
> They do:
> http://svn.debian.org/wsvn/pkg-grass/packages/grass/branches/6.1/debian/patches/xterm-fix.dpatch?op=file&rev=0&sc=0
>
> Should we invent a 'grass-xterm' script (in $ETC?) for
> that? What would be the needed content (thinking portability)?That's one option; another is an environment variable, GRASS_XTERM. If
a wrapper script is used, it should check $GRASS_XTERM before falling
back to x-terminal-emulator or xterm.
Based on above diff I have prepared a wrapper script and a patch:
http://mpa.itc.it/markus/xterm_wrapper/
I am not sure if and where the 'exec's are needed (see patch)
In the longer term, we need to make more progress on eliminating the
need for a terminal. The inability to access certain functionality
without a (curses-compatible) terminal should be considered a bug.
Agreed.
Markus
Markus Neteler wrote:
> > Debian folks are unhappy with the hardcoded 'xterm' in
> > many places and suggest to replace it with a wrapper script so
> > that they have to change it in a single place later.
> >
> > They do:
> > http://svn.debian.org/wsvn/pkg-grass/packages/grass/branches/6.1/debian/patches/xterm-fix.dpatch?op=file&rev=0&sc=0
> >
> > Should we invent a 'grass-xterm' script (in $ETC?) for
> > that? What would be the needed content (thinking portability)?
>
> That's one option; another is an environment variable, GRASS_XTERM. If
> a wrapper script is used, it should check $GRASS_XTERM before falling
> back to x-terminal-emulator or xterm.Based on above diff I have prepared a wrapper script and a patch:
http://mpa.itc.it/markus/xterm_wrapper/
I am not sure if and where the 'exec's are needed (see patch)
I suggest ending the script with:
# run command
exec $GRASS_XTERM "$@"
The lines which are executed after xterm completes aren't meaningful
unless you're running from a terminal, which won't be the case in any
situation where the script is actually used (the only reason for
spawning an xterm is if you don't already have a terminal, i.e. when
running commands from d.m/gis.m).
The wrapper should probably go into $GISBASE/etc, in which case the
patch needs to use $GISBASE/etc/grass-xterm-wrapper (or
$env(GISBASE)/etc/grass-xterm-wrapper for Tcl code) rather than just
grass-xterm-wrapper.
Also, Init.sh should probably set GRASS_XTERM to x-terminal-emulator
if it is available. IIRC, x-terminal-emulator runs the user's
preferred terminal emulator (xterm, kterm etc), so it should always be
preferred over xterm if it's available.
--
Glynn Clements <glynn@gclements.plus.com>
On Sun, Aug 27, 2006 at 07:58:22PM +0100, Glynn Clements wrote:
Markus Neteler wrote:
> > > Debian folks are unhappy with the hardcoded 'xterm' in
> > > many places and suggest to replace it with a wrapper script so
> > > that they have to change it in a single place later.
> > >
> > > They do:
> > > http://svn.debian.org/wsvn/pkg-grass/packages/grass/branches/6.1/debian/patches/xterm-fix.dpatch?op=file&rev=0&sc=0
> > >
> > > Should we invent a 'grass-xterm' script (in $ETC?) for
> > > that? What would be the needed content (thinking portability)?
> >
> > That's one option; another is an environment variable, GRASS_XTERM. If
> > a wrapper script is used, it should check $GRASS_XTERM before falling
> > back to x-terminal-emulator or xterm.
>
> Based on above diff I have prepared a wrapper script and a patch:
>
> http://mpa.itc.it/markus/xterm_wrapper/
>
> I am not sure if and where the 'exec's are needed (see patch)I suggest ending the script with:
# run command
exec $GRASS_XTERM "$@"The lines which are executed after xterm completes aren't meaningful
unless you're running from a terminal, which won't be the case in any
situation where the script is actually used (the only reason for
spawning an xterm is if you don't already have a terminal, i.e. when
running commands from d.m/gis.m).The wrapper should probably go into $GISBASE/etc, in which case the
patch needs to use $GISBASE/etc/grass-xterm-wrapper (or
$env(GISBASE)/etc/grass-xterm-wrapper for Tcl code) rather than just
grass-xterm-wrapper.Also, Init.sh should probably set GRASS_XTERM to x-terminal-emulator
if it is available. IIRC, x-terminal-emulator runs the user's
preferred terminal emulator (xterm, kterm etc), so it should always be
preferred over xterm if it's available.
Thanks for your comments. I have implemented all of them,
revised patch at
http://mpa.itc.it/markus/xterm_wrapper/
One problem remains:
etc/grass-run.sh seems to fail (now?). I tested:
gis.m
-> Raster
-> Map calculator
-> Formula: 1
Resulting output map: mytest
-> Run runs ok, but
Run in Xterm fails with
/home/neteler/soft/61grass_cvsexp/dist.i686-pc-linux-gnu/etc/grass-run.sh: line 30: : command not found
this line contains "$@". Seems to be tricky with a script calling
a program calling a script ...
Markus
On Sun, Aug 27, 2006 at 09:39:03PM +0200, Markus Neteler wrote:
On Sun, Aug 27, 2006 at 07:58:22PM +0100, Glynn Clements wrote:
>
> Markus Neteler wrote:
>
> > > > Debian folks are unhappy with the hardcoded 'xterm' in
> > > > many places and suggest to replace it with a wrapper script so
> > > > that they have to change it in a single place later.
> > > >
> > > > They do:
> > > > http://svn.debian.org/wsvn/pkg-grass/packages/grass/branches/6.1/debian/patches/xterm-fix.dpatch?op=file&rev=0&sc=0
> > > >
> > > > Should we invent a 'grass-xterm' script (in $ETC?) for
> > > > that? What would be the needed content (thinking portability)?
> > >
> > > That's one option; another is an environment variable, GRASS_XTERM. If
> > > a wrapper script is used, it should check $GRASS_XTERM before falling
> > > back to x-terminal-emulator or xterm.
> >
> > Based on above diff I have prepared a wrapper script and a patch:
> >
> > http://mpa.itc.it/markus/xterm_wrapper/
> >
> > I am not sure if and where the 'exec's are needed (see patch)
>
> I suggest ending the script with:
>
> # run command
> exec $GRASS_XTERM "$@"
>
> The lines which are executed after xterm completes aren't meaningful
> unless you're running from a terminal, which won't be the case in any
> situation where the script is actually used (the only reason for
> spawning an xterm is if you don't already have a terminal, i.e. when
> running commands from d.m/gis.m).
>
> The wrapper should probably go into $GISBASE/etc, in which case the
> patch needs to use $GISBASE/etc/grass-xterm-wrapper (or
> $env(GISBASE)/etc/grass-xterm-wrapper for Tcl code) rather than just
> grass-xterm-wrapper.
>
> Also, Init.sh should probably set GRASS_XTERM to x-terminal-emulator
> if it is available. IIRC, x-terminal-emulator runs the user's
> preferred terminal emulator (xterm, kterm etc), so it should always be
> preferred over xterm if it's available.Thanks for your comments. I have implemented all of them,
revised patch athttp://mpa.itc.it/markus/xterm_wrapper/
One problem remains:
etc/grass-run.sh seems to fail (now?). I tested:gis.m
-> Raster
-> Map calculator
-> Formula: 1
Resulting output map: mytest-> Run runs ok, but
Run in Xterm fails with/home/neteler/soft/61grass_cvsexp/dist.i686-pc-linux-gnu/etc/grass-run.sh: line 30: : command not found
this line contains "$@". Seems to be tricky with a script calling
a program calling a script ...
For the ease of testing I have submitting the patch
to CVS-HEAD. I don't expect problems but it remains above issue
with etc/grass-run.sh.
Markus
On Sun, Aug 27, 2006 at 07:58:22PM +0100, Glynn Clements wrote:
IIRC, x-terminal-emulator runs the user's
preferred terminal emulator (xterm, kterm etc), so it should always be
preferred over xterm if it's available.
Right, admin can manage that by update-alternatives.
--
Francesco P. Lovergine
Markus Neteler wrote:
Thanks for your comments. I have implemented all of them,
revised patch athttp://mpa.itc.it/markus/xterm_wrapper/
One problem remains:
etc/grass-run.sh seems to fail (now?). I tested:gis.m
-> Raster
-> Map calculator
-> Formula: 1
Resulting output map: mytest-> Run runs ok, but
Run in Xterm fails with/home/neteler/soft/61grass_cvsexp/dist.i686-pc-linux-gnu/etc/grass-run.sh: line 30: : command not found
this line contains "$@". Seems to be tricky with a script calling
a program calling a script ...
It seems to work for me, although I've only tested it briefly (copy
grass-xterm-wrapper and updated r.mapcalculator into installation
directory, run r.mapcalculator manually).
I note that r.mapcalculator doesn't use grass-run.sh, so it will have
problems if xterm is setuid/setgid. Also, outfile= and formula= are
listed as required, although they aren't needed if you use -e.
One minor point: I thought that using "which" was advised against, as
it isn't present on all platforms. If it is used, stderr should be
redirected to /dev/null, to silence the errors about
x-terminal-emulator not being found.
Also, the LD_LIBRARY_PATH=$GRASS_LD_LIBRARY_PATH in
grass-xterm-wrapper is unnecessary.
--
Glynn Clements <glynn@gclements.plus.com>
Glynn Clements wrote:
One minor point: I thought that using "which" was advised against, as
it isn't present on all platforms.
On what platforms is it missing? If `which` is missing, what are the
chances that other assumed unix tools are missing? (ie everything breaks)
If it is used, stderr should be redirected to /dev/null, to silence
the errors about x-terminal-emulator not being found.
On what platforms does `which` not return silence if the target isn't
found?
?,
Hamish
Where are hard-coded xterm references causing a problem? Is it only in the
GUI or is it elsewhere?
If only in the GUI, there is already a wrapper for nearly all xterm use. We
just need to make it consistent across the entire set of TclTk scripts.
Also, if it is just in the GUI, it might be better to make the wrapper in
TclTk than a shell script. If we need it elsewhere, however, I guess a shell
script is the way to go.
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
From: Markus Neteler <neteler@itc.it>
Date: Sun, 27 Aug 2006 15:09:42 +0200
To: GRASS developers list <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] hardcoded 'xterm': wrapper?On Sun, Aug 27, 2006 at 12:52:35PM +0100, Glynn Clements wrote:
Markus Neteler wrote:
Debian folks are unhappy with the hardcoded 'xterm' in
many places and suggest to replace it with a wrapper script so
that they have to change it in a single place later.They do:
http://svn.debian.org/wsvn/pkg-grass/packages/grass/branches/6.1/debian/patc
hes/xterm-fix.dpatch?op=file&rev=0&sc=0Should we invent a 'grass-xterm' script (in $ETC?) for
that? What would be the needed content (thinking portability)?That's one option; another is an environment variable, GRASS_XTERM. If
a wrapper script is used, it should check $GRASS_XTERM before falling
back to x-terminal-emulator or xterm.Based on above diff I have prepared a wrapper script and a patch:
http://mpa.itc.it/markus/xterm_wrapper/
I am not sure if and where the 'exec's are needed (see patch)
In the longer term, we need to make more progress on eliminating the
need for a terminal. The inability to access certain functionality
without a (curses-compatible) terminal should be considered a bug.Agreed.
Markus
Glynn Clements wrote on 08/28/2006 01:01 AM:
Markus Neteler wrote:
Thanks for your comments. I have implemented all of them,
revised patch athttp://mpa.itc.it/markus/xterm_wrapper/
One problem remains:
etc/grass-run.sh seems to fail (now?). I tested:gis.m
-> Raster
-> Map calculator
-> Formula: 1
Resulting output map: mytest-> Run runs ok, but
Run in Xterm fails with/home/neteler/soft/61grass_cvsexp/dist.i686-pc-linux-gnu/etc/grass-run.sh: line 30: : command not found
this line contains "$@". Seems to be tricky with a script calling
a program calling a script ...
It seems to work for me, although I've only tested it briefly (copy
grass-xterm-wrapper and updated r.mapcalculator into installation
directory, run r.mapcalculator manually).I note that r.mapcalculator doesn't use grass-run.sh, so it will have
problems if xterm is setuid/setgid. Also, outfile= and formula= are
listed as required, although they aren't needed if you use -e.
I will leave that to the author of r.mapcalculator.
One minor point: I thought that using "which" was advised against, as
it isn't present on all platforms. If it is used, stderr should be
redirected to /dev/null, to silence the errors about
x-terminal-emulator not being found.
I do remember discussions on 'which' use, but not the outcome. So far
it is used quite a bit:
cd scripts
grep which */* |grep '\[ ' | wc -l
58
Also, the LD_LIBRARY_PATH=$GRASS_LD_LIBRARY_PATH in
grass-xterm-wrapper is unnecessary.
OK, removed.
But I thought that it would address above mentioned setuid/setgid issue:
http://grass.itc.it/pipermail/grass5/2004-September/015409.html
Markus
Michael Barton wrote on 08/28/2006 07:40 AM:
Where are hard-coded xterm references causing a problem? Is it only in the
GUI or is it elsewhere?
Also elsewhere. They are a problem e.g. on Debian where
x-terminal-emulator should
be used.
Now the script (lib/init/grass-xterm-wrapper):
1. checks if $GRASS_XTERM is set, if not
2. searches if x-terminal-emulator is present, if not
3. uses xterm.
If only in the GUI, there is already a wrapper for nearly all xterm use. We
just need to make it consistent across the entire set of TclTk scripts.
This was not the case. At least it wasn't used.
Also, if it is just in the GUI, it might be better to make the wrapper in
TclTk than a shell script. If we need it elsewhere, however, I guess a shell
script is the way to go.
Done so (the latter).
Markus
Michael Barton wrote:
Where are hard-coded xterm references causing a problem? Is it only in
the GUI or is it elsewhere?
$ cd grass63-src/
$ grep -rI xterm *
debian/control:Depends: ${shlibs:Depends}, xterm, libgrass
debian/changelog: - depend on xterm
gem/main.c: - a simple wrapper g.install with GRASS style parameters. Should start an xterm and ask for su pwd,
gui/tcltk/gis.m/runandoutput.tcl: set runxterm [button $cmdpane.xterm -text [G_msg "Run in Xterm"] -command "$gronsole run_xte \[string trim \[$cmdtext get 1.0 end\]\] {}"]
gui/tcltk/gis.m/runandoutput.tcl: pack $runbutton $run2button $runuibutton $runxterm \
gui/tcltk/gis.m/runandoutput.tcl: $gronsole run_xterm $cmd gism
gui/tcltk/gis.m/runandoutput.tcl: eval [list exec -- xterm -name xterm-grass -e $env(GISBASE)/etc/grass-run.sh $cmd] $args &
gui/tcltk/gis.m/script/r.support.sh:eval `exec xterm -e r.support map=$GIS_OPT_INPUT`
gui/tcltk/gis.m/script/r.reclass.rules:exec xterm -e "$GISBASE/etc/grass-run.sh" r.reclass "input=$GIS_OPT_INPUT" "output=$GIS_OPT_O PUT"
gui/tcltk/gis.m/script/d.colors.sh:# PURPOSE: Make xterm module d.colors useable from the GUI
gui/tcltk/gis.m/script/d.colors.sh:exec xterm -e "$GISBASE/etc/grass-run.sh" d.colors "map=$GIS_OPT_INPUT"
gui/tcltk/gis.m/script/r.colors.rules:exec xterm -e "$GISBASE/etc/grass-run.sh" r.colors "map=$GIS_OPT_INPUT" color=rules
gui/tcltk/gis.m/script/r.recode.rules:exec xterm -e "$GISBASE/etc/grass-run.sh" r.recode "input=$GIS_OPT_INPUT" "output=$GIS_OPT_OUT T"
gui/tcltk/gis.m/script/d.text.sh:exec xterm -e "$GISBASE/etc/grass-run.sh" $cmd
gui/tcltk/d.m/vector.tcl: exec xterm -bg $bgcolor -title "$mapname columns" \
gui/tcltk/d.m/vector.tcl: exec xterm -bg $bgcolor -title "$mapname data" \
gui/tcltk/d.m/thematic.tcl: exec xterm -bg $bgcolor -title "$mapname columns" \
gui/tcltk/d.m/thematic.tcl: exec xterm -bg $bgcolor -title "$mapname data" \
gui/tcltk/d.m/script/r.support.sh:eval `exec xterm -e r.support map=$GIS_OPT_INPUT`
gui/tcltk/d.m/script/r.reclass.rules:eval `exec xterm -e r.reclass input=$GIS_OPT_INPUT output=$GIS_OPT_OUTPUT`
gui/tcltk/d.m/script/d.colors.sh:# PURPOSE: Make xterm module d.colors useable from the GUI
gui/tcltk/d.m/script/d.colors.sh:eval `exec xterm -e d.colors map=$GIS_OPT_INPUT`
gui/tcltk/d.m/script/r.colors.rules:eval `exec xterm -e r.colors map=$GIS_OPT_INPUT color=rules`
gui/tcltk/d.m/script/r.recode.rules:eval `exec xterm -e r.recode input=$GIS_OPT_INPUT output=$GIS_OPT_OUTPUT`
gui/tcltk/d.m/script/d.text.sh:eval `exec xterm -e $cmd`
gui/tcltk/d.m/d.m.tcl: eval exec -- xterm -name xterm-grass -e $env(GISBASE)/etc/grass-run.sh $cmd &
gui/tcltk/d.m/d.m.tcl: eval exec -- xterm -name xterm-grass -e $env(GISBASE)/etc/grass-run.sh $cmd $args &
gui/tcltk/d.m/chart.tcl: exec xterm -bg $bgcolor -title "$mapname columns" \
gui/wxpython/scripts/r.support.sh:eval `exec xterm -e r.support map=$GIS_OPT_INPUT`
gui/wxpython/scripts/r.reclass.rules:exec xterm -e "$GISBASE/etc/grass-run.sh" r.reclass "input=$GIS_OPT_INPUT" "output=$GIS_OPT_OUT T"
gui/wxpython/scripts/r.colors.rules:exec xterm -e "$GISBASE/etc/grass-run.sh" r.colors "map=$GIS_OPT_INPUT" color=rules
gui/wxpython/scripts/r.recode.rules:exec xterm -e "$GISBASE/etc/grass-run.sh" r.recode "input=$GIS_OPT_INPUT" "output=$GIS_OPT_OUTPU
lib/init/epsg_option.tcl.in: exec -- xterm -e $env(GISBASE)/etc/make_location_epsg.sh \
lib/init/grass-run.src:if [ "$TERM" = "xterm" ] ; then
lib/init/grass-run.src:# workaround for systems with xterm is setuid/setgid
lib/vask/README:happen with xterm, which has many configuration options which impact
lib/vask/V_init.c: system("clear"); /* this is a kludge - xterm has problems
lib/gtcltk/gronsole.tcl:proc Gronsole::run_xterm {path cmd tags} {
lib/gtcltk/gronsole.tcl: Gronsole::annotate $path $cmd [concat xterm $tags]
lib/gtcltk/gronsole.tcl: exec -- xterm -name xterm-grass -e $env(GISBASE)/etc/grass-run.sh $cmd &
lib/external/bwidget/entry.tcl: $path:cmd configure -cursor xterm
scripts/r.mapcalculator/r.mapcalculator: exec xterm -e r.mapcalc &
scripts/r3.mapcalculator/r3.mapcalculator: exec xterm -e r3.mapcalc &
Hamish
Hamish wrote:
> One minor point: I thought that using "which" was advised against, as
> it isn't present on all platforms.On what platforms is it missing? If `which` is missing, what are the
chances that other assumed unix tools are missing? (ie everything breaks)
I don't know, but SUBMITTING_SCRIPTS says:
5. If you search for a command in $PATH, do NOT
use the "which" command or the "type -p" command. Both commands are not
supported on all platforms, thus causing problems for some people. As an
alternative, please use code similar to the following shell script snippet
which will perform the same function. In this case, the path of the grass60
command is saved if grass60 is found in $PATH. This won't recognize aliased
command name.
# Search for grass5 command in user's path
for i in `echo $PATH | sed 's/^:/.
s/::/:.:/g
s/:$/:./
s/ /g'`
do
if [ -f $i/grass5 ] ; then
# Save the path of the grass60 command
GRASS_PATH=$i/grass60
# Use the first one in user's path
break
fi
done
<?>
If you must use "which", use as follows:
# check if we have awk
if [ ! -x "`which awk`" ] ; then
echo "ERROR: awk required, please install awk or gawk first" 1>&2
exit 1
fi
</?>
> If it is used, stderr should be redirected to /dev/null, to silence
> the errors about x-terminal-emulator not being found.On what platforms does `which` not return silence if the target isn't
found?
The GNU version isn't silent:
glynn@cerise:6.1 $ which foo
which: no foo in (/opt/grass-6.3.cvs/bin:/opt/grass-6.3.cvs/scripts:<snip>)
--
Glynn Clements <glynn@gclements.plus.com>
Markus Neteler wrote:
> Also, the LD_LIBRARY_PATH=$GRASS_LD_LIBRARY_PATH in
> grass-xterm-wrapper is unnecessary.OK, removed.
But I thought that it would address above mentioned setuid/setgid issue:
http://grass.itc.it/pipermail/grass5/2004-September/015409.html
No, it has to be done by the command which xterm runs. Setting it
prior to running xterm won't have any effect, as it's the act of
running a setuid/setgid executable (e.g. xterm) which clears
LD_LIBRARY_PATH.
--
Glynn Clements <glynn@gclements.plus.com>
Glynn Clements wrote:
> > One minor point: I thought that using "which" was advised against,
> > as it isn't present on all platforms.
Hamish wrote:
> On what platforms is it missing? If `which` is missing, what are the
> chances that other assumed unix tools are missing? (ie everything
> breaks)I don't know, but SUBMITTING_SCRIPTS says:
5. If you search for a command in $PATH, do NOT
use the "which" command or the "type -p" command. Both commands
are not supported on all platforms, thus causing problems for
some people. As an alternative, please use code similar to the
following shell script snippet which will perform the same
function. In this case, the path of the grass60 command is saved
if grass60 is found in $PATH. This won't recognize aliased
command name.
# Search for grass5 command in user's path
for i in `echo $PATH | sed 's/^:/.
s/::/:.:/g
s/:$/:./
s/
do
if [ -f $i/grass5 ] ; then
# Save the path of the grass60 command
GRASS_PATH=$i/grass60
# Use the first one in user's path
break
fi
done
Yes, I was aware of that, but was ignoring it as it has been many years
since anyone reported an error with it and I never heard an explicit
example of a platform where it wasn't present.
fyi, I am responsible for adding this:
<?>
If you must use "which", use as follows:
# check if we have awk
if [ ! -x "`which awk`" ] ; then
echo "ERROR: awk required, please install awk or gawk first"
1>&2 exit 1
fi
</?>
> > If it is used, stderr should be redirected to /dev/null, to
> > silence the errors about x-terminal-emulator not being found.
>
> On what platforms does `which` not return silence if the target
> isn't found?The GNU version isn't silent:
glynn@cerise:6.1 $ which foo
which: no foo in
(/opt/grass-6.3.cvs/bin:/opt/grass-6.3.cvs/scripts:<snip>)
ok, so how about this:
If you must use "which", use as follows:
# check if we have awk
if [ ! -x "`which awk 2> /dev/null`" ] ; then
echo "ERROR: awk required, please install awk or gawk first"
1>&2 exit 1
fi
I found these messages in the archives:
http://grass.itc.it/pipermail/grass-dev/2001-April/009332.html
(supposedly missing on Cray & Solaris*)
http://grass.itc.it/pipermail/grass-dev/2001-April/009280.html
http://grass.itc.it/pipermail/grass-dev/2001-April/009350.html
[*] `which` was apparently missing on Cray & Solaris, but I think that
the test used in that first email is incorrect. In fact on my linux:
$ alias which
bash: alias: which: not found
$ type -p which
/usr/bin/which
so which is there, just not an alias. I'm still not convinced the
problem actually exists.
If we do need to use the `echo $PATH | sed..` method, I'd suggest
writing it as a small script (returning 0 or 1) and moving it to
$GISBASE/etc/ rather than cutting and pasting that ugly mess into
all the scripts that need it.
??,
Hamish
Hamish wrote:
Yes, I was aware of that, but was ignoring it as it has been many years
since anyone reported an error with it and I never heard an explicit
example of a platform where it wasn't present.
FWIW, "which" is normally a separate package, so it's possible that it
hasn't been installed even if it is available. But then the same is
true for sed, awk etc.
It isn't required by the Single Unix Specification, although "type" is
(but not the -p switch).
ok, so how about this:
> If you must use "which", use as follows:
>
> # check if we have awk
> if [ ! -x "`which awk 2> /dev/null`" ] ; then
> echo "ERROR: awk required, please install awk or gawk first"
> 1>&2 exit 1
> fi
That looks okay, although personally I wouldn't bother checking for
something as standard as awk.
If we do need to use the `echo $PATH | sed..` method, I'd suggest
writing it as a small script (returning 0 or 1) and moving it to
$GISBASE/etc/ rather than cutting and pasting that ugly mess into
all the scripts that need it.
We shouldn't ever actually need the full path to a program; if it's in
the path, we can just run it using its name. I'd be more inclined to
check for a program by using a test case. If the test fails, either
the program isn't present, or it doesn't work; we don't really need to
distinguish between the two.
E.g.:
result=`awk 'BEGIN {print "working"}' 2>/dev/null`
if [ $? != 0 -o "$result" != "working" ] ; then
echo missing or broken \"awk\" >&2
exit 1
fi
--
Glynn Clements <glynn@gclements.plus.com>
Glynn Clements wrote:
It seems to work for me,
After this change any command from d.m that spawns terminal (d.zoom,
r.digit etc.) is broken on my Ubuntu Dapper, where gnome-terminal is a
default terminal.
In spearfish60:
$ d.m
add any layer
display it
press Zoom
gnome-terminal pops-up saying:
---
/usr/local/grass-6.3.cvs/etc/grass-run.sh: line 30: d.zoom: command not
found
ERROR: d.zoom exited abnormally. Press <enter> to continue.
---
And on the Grass terminal I get:
---
Option --tclass is no longer supported in this version of
gnome-terminal; you might want to create a profile with the desired
setting, and use the new --window-with-profile option
---
Maciek
Maciej Sieczka wrote:
> It seems to work for me,
After this change any command from d.m that spawns terminal (d.zoom,
r.digit etc.) is broken on my Ubuntu Dapper, where gnome-terminal is a
default terminal.In spearfish60:
$ d.m
add any layer
display it
press Zoomgnome-terminal pops-up saying:
---
/usr/local/grass-6.3.cvs/etc/grass-run.sh: line 30: d.zoom: command not
foundERROR: d.zoom exited abnormally. Press <enter> to continue.
---
It appears that gnome-terminal resets $PATH.
In which case, you need to either set GRASS_XTERM to "xterm" to force
the use of an xterm instead, or figure out how to make gnome-terminal
preserve $PATH.
And on the Grass terminal I get:
---
Option --tclass is no longer supported in this version of
gnome-terminal; you might want to create a profile with the desired
setting, and use the new --window-with-profile option
That would appear to be a problem with the x-terminal-emulator script
passing gnome-terminal options which it doesn't understand.
--
Glynn Clements <glynn@gclements.plus.com>
Glynn Clements wrote:
Maciej Sieczka wrote:
It seems to work for me,
After this change any command from d.m that spawns terminal (d.zoom,
r.digit etc.) is broken on my Ubuntu Dapper, where gnome-terminal is a
default terminal.In spearfish60:
$ d.m
add any layer
display it
press Zoomgnome-terminal pops-up saying:
---
/usr/local/grass-6.3.cvs/etc/grass-run.sh: line 30: d.zoom: command not
foundERROR: d.zoom exited abnormally. Press <enter> to continue.
---It appears that gnome-terminal resets $PATH.
In which case, you need to either set GRASS_XTERM to "xterm" to force
the use of an xterm instead, or figure out how to make gnome-terminal
preserve $PATH.
gnome-terminal is a default terminal for Gnome as you know. That means
that not only I, but most Gnome would have to do it. This means that
d.m in Grass 6.3 will be broken on many Linux boxes by default. If we
don't want it, shouldn't the change that breaks Grass 6.3 on Gnome
should be reverted?
What was wrong about using xterm by deafult?
And on the Grass terminal I get:
---
Option --tclass is no longer supported in this version of
gnome-terminal; you might want to create a profile with the desired
setting, and use the new --window-with-profile optionThat would appear to be a problem with the x-terminal-emulator script
passing gnome-terminal options which it doesn't understand.
I could fix the problem for me, but I worry about other users who might
not be able to.
Maciek