multi-g.manuals; concurrency locking

[Mark P. Line]

On Thu, 24 Mar 1994, Frank Davis 912/386-3889 wrote:

> For the learning impaired, wonder if it would be useful to modify
> g.manual?  I have trouble remembering what I did five minutes ago and
> I surely have a terrible time remembering GRASS commands.

g.manual might need some modification, but not for what you're asking ...

> I tried to open another window in X (I think that's the right terminology),
> so I could view the on-line GRASS manual in one window and enter commands
> in another window.  Unfortunately, GRASS gives a "concurrent use not
> allowed" error message.

I assume you're entering commands in an 'xterm' window. You start GRASS in
that window with 'grass4.1', enter the directory stuff in the entry mask,
and press ESCAPE to leave the mask. You can now enter commands such as
'g.manual'. All you have to do now is enter

    xterm &

to start a *second* 'xterm' window as a background subprocess of your
ongoing GRASS session. In the second xterm window (or the first, it
doesn't matter), you can now start 'g.manual' and just leave it running.
You can even start a third xterm window to run g.help permanently during
your session. 

Isn't Unix neat?    %^)

> I hardly know Unix and I can barely read C.  But after looking in
> src/general/g.manual, the usual Unix commands are used to display
> GRASS man pages.
> 
> The question I want answered is why should g.manual care if I'm already
> running GRASS?

g.manual doesn't care, in fact. But you can't start a second GRASS session
while the first one is still in progress. I think it should be different
myself, but that's the way all the GRASS sites I've seen are set up. But
you don't need to start a second session just in order to have multiple X
windows into the same session.

BTW, does anybody know for sure what happens if you simply disable the
concurrency locking mechanism in GIS.sh? I actually wanted to set up a lab
sometime soon with a large server and multiple PC's running X11 emulation
software over TCP/IP to the server, and run GRASS from each PC. I guess
that might be hard to do with the concurrency locks in place.

> I would find it really and very useful to open a window or two
> for g.manual.  Wonder how hard it would be to modify g.manual
> so help could be displayed in several windows?

You might want to start with some Unix & X manuals concurrently with your
perusal of the GRASS manuals. Otherwise, you might be inclined to do
things like modify g.manual to accomplish things that Unix and X are
designed to do.

One difference between GRASS and some other large systems with which you
might be familiar is that GRASS relies heavily on functionality already
existing in the platform. A better way of stating this is that GRASS does
not redundantly implement functionality that's already provided by its
platform. So, instead of a proprietary macro language (that I decline to
name) that always has a forty-million-entry wish list for extensions and
improvements, GRASS is designed to interoperate with standard Unix shells
and other powerful utilities that are likewise subject to international
standards. 

-- Mark

--------------------------------------------------------------------
Mark P. Line                       Phone: +1-206-733-6040
Open Pathways                        Fax: +1-206-733-6040
P.O. Box F                         Email: markline at henson.cc.wwu.edu
Bellingham, WA 98227-0296
--------------------------------------------------------------------