[GRASS5] which, less and SUBMITTING

Hallo,

as you told me, 'which' is not available on some systems. So I wrote a
shell-script G_which, following the instructions in SUBMITTING, that can
be used as a replacement for 'which' in most cases.

I think, using this script will make writing, reading and understanding
scripts easier.
It can also be used to correct the scripts still using 'which' (I found
four in the current beta-release: g.man2html, r.to.pg, s.in.garmin.sh,
v.in.garmin.sh) within a few seconds.

It can also be used, to make 'less' available for the systems, where it
is available. The code in init.sh could look like this:

# Set some environment variables if they are not set
if [ ! "$PAGER" ] ; then
  G_which less > /dev/null
  if [ $? = 0 ] ; then
  PAGER=less
  else
    PAGER=more
    fi
    export PAGER
fi

I still think, that 'less' should be used. And I don't think, it is up
to the user to get it working. Most users will only notify, that less
doesn't work, but only a few of them will be able to fix it on their
own.

Comments on SUBMITTING:
If you look at the start of the document, it looks like a cvs-HOWTO. But
it contains much more than this, so maybe someone could add a hint in
the first lines, that it also contains basic programming instructions.
Also I would suggest, it should go in the binary distribution: People
writing shell-scripts they consider usefull for others don't have
necessarilly the source-tree installed.

Regards
Reinhard

(attachments)

G_which.gz (596 Bytes)

Reinhard Brunzema wrote:

as you told me, 'which' is not available on some systems. So I wrote a
shell-script G_which, following the instructions in SUBMITTING, that can
be used as a replacement for 'which' in most cases.

There is also a "whereis" command that can be used, or even the builtin
type command (in all bourne compatible shell). They don't allways give
the same result, but type is IMHO a good solution too. Ex :

bash-2.03$ type echo
echo is a shell builtin
bash-2.03$ which echo
/bin/echo
bash-2.03$ whereis echo
echo: /bin/echo
bash-2.03$ type less
less is /usr/bin/less
bash-2.03$ less
Missing filename ("less --help" for help)
bash-2.03$ type less
less is hashed (/usr/bin/less)

--
Michel WURTZ - DIG - Maison de la télédétection
               500, rue J.F. Breton
               34093 MONTPELLIER Cedex 5

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

Hi Reinhard,

one simple question: Why don't you put a "export PAGER=less" in your
.profile or .bashrc (or other startup file depending on your favourite
shell)?
This would allow individual customization of the pager, which is in my
eyes the purpose of the GRASS initialization setup. The code in init.sh
is IMHO only providing a fallback in case no PAGER variable is set.

The problem with the G_which shell script is that the scripts depending
on which (some of them are written by me, i admit), must be changed.

Under cygwin/windows i created a system wide script which looks like
that:

#!/bin/sh
SAVEIFS="$IFS"
IFS=":"
FOUND=""
for FILE in $PATH ; do
   if [ -x "$FILE/$1" ] ; then
      FOUND="$FILE/$1"
   fi
done
IFS="$SAVEIFS"
echo -n $FOUND

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

Andreas Lange schrieb:

Hi Reinhard,

one simple question: Why don't you put a "export PAGER=less" in your
.profile or .bashrc (or other startup file depending on your favourite
shell)?

This would fix the problem on my machine, but not anywhere else in the
world.
The real problem is, currently GRASS changes the default behavior of
parts of the system. Linux users expect man running the 'less-way'. When
they try to read a man page in GRASS they will get confused, because
they can't use the arrow keys.
They look for help, GRASS makes them confused - Not a friendly behavior.

When they want the old and common behavior of the man pages back, they
have to do a lot of work. I don't mean adding PAGER=less in a
configuration file - I mean finding out, what they have to do. You have
to be a unix/linux expert or at least a advanced user to know that PAGER
is related to man.

In general I think, a program should keep as much work away from the
user as possible.

When you look in the Changelog, you see, that in most cases PAGER is
used to _replace_ more. On linux-systems it does the opposite. IMHO
that's a bug.

This would allow individual customization of the pager, which is in my
eyes the purpose of the GRASS initialization setup. The code in init.sh
is IMHO only providing a fallback in case no PAGER variable is set.

The new code wouldn't change that behavior. It's just a better fallback.

The problem with the G_which shell script is that the scripts depending
on which (some of them are written by me, i admit), must be changed.

I was told on this list, that it 'which' is not portable enough. So I
looked for a better portable replacement, that can easely be used.

Under cygwin/windows i created a system wide script which looks like
that:

#!/bin/sh
SAVEIFS="$IFS"
IFS=":"
FOUND=""
for FILE in $PATH ; do
   if [ -x "$FILE/$1" ] ; then
      FOUND="$FILE/$1"
   fi
done
IFS="$SAVEIFS"
echo -n $FOUND

Great! This looks like an easier solution and it is independent of
'sed'. You should add a return value dependend on
successfull/unsuccessfull search, because some of the 'which scripts'
work with that value. After this it should go in the GRASS
distributions, so everyone can work with it (IMHO).

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

Michel Wurtz schrieb:

There is also a "whereis" command that can be used, or even the builtin
type command (in all bourne compatible shell). They don't allways give
the same result, but type is IMHO a good solution too. Ex :

Markus pointed out, that even 'type' is not always available. And I
don't know anything about 'whereis'. It can be used on my linux system,
but what about the other supported platforms?

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

Reinhard Brunzema wrote:

Linux users expect man running the 'less-way'.

So what? The world does not revolve around Linux users, or their
expectations.

Having said that, I do agree that programs shouldn't try to override
system defaults. System environment variables (PAGER etc) should be
left alone; i.e. if PAGER is unset, it should be left unset (which
should cause "man" to use whatever pager is specified in
"man.config").

If it's too much effort to make GRASS' code handle the case where no
pager is specified (e.g. if lots of files use something like
popen("$PAGER")), the simplest fix is to use a different environment
variable (e.g. GRASS_PAGER) within GRASS. The startup could then
ensure that this is set to something whilst leaving PAGER alone.

When they want the old and common behavior of the man pages back, they
have to do a lot of work. I don't mean adding PAGER=less in a
configuration file - I mean finding out, what they have to do. You have
to be a unix/linux expert or at least a advanced user to know that PAGER
is related to man.

Well, you have to be capable of reading the man(1) manpage. It's a
pretty sad state of affairs when that is considered the preserve of
"advanced" users.

In general I think, a program should keep as much work away from the
user as possible.

That doesn't mean it should do things that aren't its responsibility;
that way lies needless complexity, which only makes the program harder
to understand and its behaviour less predictable.

> This would allow individual customization of the pager, which is in my
> eyes the purpose of the GRASS initialization setup. The code in init.sh
> is IMHO only providing a fallback in case no PAGER variable is set.

The new code wouldn't change that behavior. It's just a better fallback.

"Better" is subjective. "more" may be primitive, but it seldom fails
horribly, as "less" often does if curses is broken, or if termcap or
terminfo are broken[1], or if $TERM is incorrectly set[2].

Also, "less" moans about dumb terminals (ones which don't support
cursor positioning), and dumps loads of cruft into the output, which
is a nuisance if you're capturing it (e.g. with "script") for later
reference.

[1] Quite common; many people modify them to match bugs in a specific
terminal emulator. Of course, as a result, anyone with a working
terminal of the corresponding type (or emulation thereof) is totally
stuffed.

[2] also quite common; e.g. it's often set to "vt100" by programs
which don't even come close.

--
Glynn Clements <glynn.clements@virgin.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

On Wed, 11 Apr 2001, Glynn Clements wrote:

So what? The world does not revolve around Linux users, or their
expectations.

  Why not? Ignorance? Influence of Microshaft? Tsch-tsch! Something must be
done to change this poor attitude.

:slight_smile:

Rich

Dr. Richard B. Shepard, President

                       Applied Ecosystem Services, Inc. (TM)
            2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

Glynn Clements schrieb:

Reinhard Brunzema wrote:

> Linux users expect man running the 'less-way'.

So what? The world does not revolve around Linux users, or their
expectations.

Why do you metion it? Nobody said so.
Anyway, I don't see any advantage in disrespecting them or users of any
platform.

Having said that, I do agree that programs shouldn't try to override
system defaults. System environment variables (PAGER etc) should be
left alone; i.e. if PAGER is unset, it should be left unset (which
should cause "man" to use whatever pager is specified in
"man.config").

I agree.

If it's too much effort to make GRASS' code handle the case where no
pager is specified (e.g. if lots of files use something like
popen("$PAGER")), the simplest fix is to use a different environment
variable (e.g. GRASS_PAGER) within GRASS. The startup could then
ensure that this is set to something whilst leaving PAGER alone.

If that's a solution, it's okay with me.

> When they want the old and common behavior of the man pages back, they
> have to do a lot of work. I don't mean adding PAGER=less in a
> configuration file - I mean finding out, what they have to do. You have
> to be a unix/linux expert or at least a advanced user to know that PAGER
> is related to man.

Well, you have to be capable of reading the man(1) manpage.

YES! (Remember, you wanted to read a GRASS-manpage, not the man manpage)

It's a
pretty sad state of affairs when that is considered the preserve of
"advanced" users.

Sad or not, it's the truth. Keep in mind, not everybody has a system
supporting his native language. There are a lot of options, variables
and files that rule the behavior of man, in the worst case you have to
check all of them.

> In general I think, a program should keep as much work away from the
> user as possible.

That doesn't mean it should do things that aren't its responsibility;
that way lies needless complexity, which only makes the program harder
to understand and its behaviour less predictable.

As you mentioned before, this has already happened, the trouble is
already there, because we have an unexpected behavior.

> > This would allow individual customization of the pager, which is in my
> > eyes the purpose of the GRASS initialization setup. The code in init.sh
> > is IMHO only providing a fallback in case no PAGER variable is set.
>
> The new code wouldn't change that behavior. It's just a better fallback.

"Better" is subjective. "more" may be primitive, but it seldom fails
horribly, as "less" often does if curses is broken, or if termcap or
terminfo are broken[1], or if $TERM is incorrectly set[2].

You are in trouble anyway, in that case.

Also, "less" moans about dumb terminals (ones which don't support
cursor positioning),

We could use 'less -d', if this is really a major problem.

and dumps loads of cruft into the output, which
is a nuisance if you're capturing it (e.g. with "script") for later
reference.

If you use such advanved features you are probably able to set up PAGER
the way you want without any trouble.

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

On Wed, Apr 11, 2001 at 08:19:37PM +0200, Reinhard Brunzema wrote:

Michel Wurtz schrieb:
>

> There is also a "whereis" command that can be used, or even the builtin
> type command (in all bourne compatible shell). They don't allways give
> the same result, but type is IMHO a good solution too. Ex :
>
Markus pointed out, that even 'type' is not always available. And I
don't know anything about 'whereis'. It can be used on my linux system,
but what about the other supported platforms?

Unfortunately "whereis" is also not standardized :-((

CRAY:

t3e::151$ whereis echo
echo: /bin/echo /usr/man/cat1/echo.1

Linux:

whereis echo
echo: /bin/echo

Solaris:
whereis echo
echo: /usr/bin/echo /usr/ucb/echo /usr/man/man1/echo.1
/usr/man/man1b/echo.1b /usr/man/man1f/echo.1f /usr/man/man3x/echo.3x

It seems we need a script'ed solution. What about setting an
alias "GRASS_WHICH='...'" containing the script from Andreas (to be set in
etc/Init.sh). Maybe that's a solution?

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

Finally I found time to try compile GRASS on HP-UX.
I download the last snapshut of GRASS and proceeded
to compile it. So, I run ./configure and got somme
checking with negative results. I want to know if they
may cause problems.

checking for flex... lex

??? the REQUIREMENT files say flex no lex is suported.
??? flex is available for HP-UX

Are they any problems with thoses ?

checking for bison... no
checking for byacc... no

checking for dnet_ntoa in -ldnet... no
checking for dnet_ntoa in -ldnet_stub... no

checking for seteuid... no

checking for initscr in -lncurses... no
checking for initscr in -lcurses... yes

checking for xdrmem_create in -lsun... no
checking for xdrmem_create in -lnsl... no
checking for xdrmem_create in -lrpclib... no
checking for atan in -lc... no
checking for atan in -lm... yes
checking for dlsym in -ldl... no

I have some missing libraries that are easy to correct.

Thanks.

--
Robert Lagacé, professeur
Pavillon Comtois
Université Laval
Ste-Foy, Québec, G1K 7P4
tel : (418)-656-2131#2276
Fax : (418)-656-3723
E-mail : lagace@grr.ulaval.ca

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

Does GRASS require genu make or it can use UNIX make?

--
Robert Lagacé, professeur
Pavillon Comtois
Université Laval
Ste-Foy, Québec, G1K 7P4
tel : (418)-656-2131#2276
Fax : (418)-656-3723
E-mail : lagace@grr.ulaval.ca

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

Hi Robert,

Gnu make works best on Solaris with the external dependencies.
Regular Solaris make will work with tweeking in Solaris 7, but gnu is
better.

Bruce

Robert Lagacé wrote:

Does GRASS require genu make or it can use UNIX make?

--
Robert Lagacé, professeur
Pavillon Comtois
Université Laval
Ste-Foy, Québec, G1K 7P4
tel : (418)-656-2131#2276
Fax : (418)-656-3723
E-mail : lagace@grr.ulaval.ca

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

On Tue, Apr 17, 2001 at 10:04:03AM -0400, Robert Lagacé wrote:

Does GRASS require genu make or it can use UNIX make?

Hi Robert,

I am not sure, but both should do (I think on "our" CRAY it is
no gnu make).

Hope this helps,

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

to be on the safe side, go with GNU make. There may be features required
that unix make does not provide. But it may depend on which compiler you
use. (gcc with GNU make, else try the make from your system?)

Markus, if GNU make is required/recommended, we should put another note
into the REQUIREMENTS file!

cu,

Andreas

Robert Lagacé wrote:

Does GRASS require genu make or it can use UNIX make?

--
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
Andreas.Lange@Rhein-Main.de - A.C.Lange@GMX.net

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

Andreas Lange wrote:

to be on the safe side, go with GNU make. There may be features
required that unix make does not provide. But it may depend on which
compiler you use. (gcc with GNU make, else try the make from your
system?)

Markus, if GNU make is required/recommended, we should put another
note into the REQUIREMENTS file!

Actually GNU make is not required except for maybe libgdal. However, I
had proposed earlier that we make it required and use its features for
the new Makefile system so it is fine with me if we make it required.
:slight_smile:

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

Hello all

Two points on this discussion.

First "less" is not available on all platforms.

Second, if I recall correctly, Huidae Cho was the author who added the
$PAGER check. Huidae, what was the reason for adding this into Ini.sh?
Was there a platform that required $PAGER to be set? Or was it just the
preference of a user?

If $PAGER, is not actually required, then I vote that this part of
Init.sh be removed.

Just my 2 cents worth.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

Justin Hickey wrote:

Second, if I recall correctly, Huidae Cho was the author who added the
$PAGER check. Huidae, what was the reason for adding this into Ini.sh?
Was there a platform that required $PAGER to be set? Or was it just the
preference of a user?

If $PAGER, is not actually required, then I vote that this part of
Init.sh be removed.

Recursively grepping for "PAGER" produces:

src/imagery/i.ortho.photo/libes/ls_cameras.c:59: sprintf (buf, "$PAGER %s", tempfile);
src/imagery/i.ortho.photo/libes/ls_elev.c:49: sprintf (buf, "$PAGER %s", tempfile);
src/libes/imagery/ls_groups.c:68: sprintf (buf, "$PAGER %s", tempfile);
src/libes/imagery/ls_groups.c:126: sprintf (buf, "$PAGER %s", tempfile);
src/raster/r.info/inter/more_print.c:9: sprintf(command,"clear; $PAGER %s",tmpname);

The resulting string being fed to either system() or G_system().

NB: there were some references in g.manual, but these seem to have
been removed recently (since the start of the release branch).

As a stop-gap measure[1], I suggest changing $PAGER to $GRASS_PAGER
throughout, and initialising the latter in Init.sh.

[1] In the longer term, the use of system() should be abolished
altogether in favour of a function which takes individual arguments
(as with execl() et al).

--
Glynn Clements <glynn.clements@virgin.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

From: Justin Hickey <jhickey@hpcc.nectec.or.th>

Hello all

Two points on this discussion.

First "less" is not available on all platforms.

Second, if I recall correctly, Huidae Cho was the author who added the
$PAGER check. Huidae, what was the reason for adding this into Ini.sh?
Was there a platform that required $PAGER to be set? Or was it just the
preference of a user?

Hi all,

"man" needs PAGER env var to override a default pager. And if i remember
correctly, some programs want this var too. So I just used this env var
to use user's pager in GRASS.

If $PAGER, is not actually required, then I vote that this part of
Init.sh be removed.

I remember that there was inconsistency between grass modules which need pager.
So I decided to check this env var, which may be already set or not.
Using this var, we can use the same pager system widely.

If this causes any problem, PAGER may be renamed to GRASS_PAGER or etc.
Then, non-$PAGER user won't experience any inconsistency between GRASS and
UNIX.

Just my thought.

Regards,
Huidae Cho

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'