[GRASS5] which, less and SUBMITTING

[Reinhard Brunzema]

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 at geog.uni-hannover.de with
subject 'unsubscribe grass5'