Newsgroups: comp.unix.wizards
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: Re: Bourne shell programming questions
Message-ID: <1988Oct16.040253.621@utzoo.uucp>
Organization: U of Toronto Zoology
References: <120@tree.UUCP>
Date: Sun, 16 Oct 88 04:02:53 GMT

In article <120@tree.UUCP> stever@tree.UUCP (Steve Rudek) writes:
>... I'd like to expand the use of memory variables since it
>reduces the need for disk access.  How much variable space do I have to
>play with?  Is this defined or at all standardized across machines?

No.  In general, you can get whatever the system is willing to give you.
Of course, as the amount gets larger, the forks needed to execute non-
builtin commands will slow down, and the shell will be more subject to
paging.

>... There is a "hash" command
>defined for shell which is scantily described in man.  Man indicates that
>it can be used to "remember" the exact path to given commands and, thus,
>reduce the overhead of calling external programs? ...

For non-interactive applications, there is no advantage to using "hash"
and it can be ignored.  The SysV shell is smart enough to remember where it
last found a command.  All "hash" does is tell the shell to find a command
(and thus remember its location) without actually executing it.  The only
real use that I'm aware of is for interactive users who want to have some
of the finding overhead concentrated at the beginning of a session instead
of spread out over it.  I experimented with it and concluded that it was
not worth the trouble, at least on our system (we don't believe in having
57 different directories in the default search path, so finding a command
doesn't involve very many tries).
-- 
The meek can have the Earth;    |    Henry Spencer at U of Toronto Zoology
the rest of us have other plans.|uunet!attcan!utzoo!henry henry@zoo.toronto.edu