Path: utzoo!utgpu!water!watmath!clyde!att!cbnews!lml
From: lml@cbnews.ATT.COM (L. Mark Larsen)
Newsgroups: comp.unix.wizards
Subject: Re: Bourne shell programming questions
Keywords: sh  Bourne  programming  environment  hash  books
Message-ID: <1562@cbnews.ATT.COM>
Date: 16 Oct 88 01:16:03 GMT
References: <120@tree.UUCP>
Reply-To: lml@cbnews.ATT.COM (L. Mark Larsen)
Organization: AT&T Bell Laboratories, Columbus
Lines: 65

In article <120@tree.UUCP> stever@tree.UUCP (Steve Rudek) writes:
#I think the lack of decent sh documentation is a shame.  I've found that
#most UNIX "wizards" are actually only "C" wizards and have basically missed
			 ^^^^^^^^^^^^^^^^^^^^^^^^^
That may or may not be true but it certainly is sometimes true.

#the boat with regard to what (in my opinion) UNIX is all about!  Shell
#script is an immensely powerful 4th GL but most folks treat it like it is
#just a run-of-the-mill JCL and only use it for short utility programs.

I enjoy programming in shell also (and awk too - a nice combination)
#
#Anyway, enough of that; I actually wanted to ask a couple of questions!
#(1) ....  How much variable space do I have to
#play with?  Is this defined or at all standardized across machines?

I believe it is machine independent.  I believe the dependency is more
in terms of which UN*X OS you are using.  As to your first question, one
limit I know of in System V is 5,120 bytes for members of the exec family.
This includes arguments as well as the environment (shell variables).
So, any calls to non-builtin programs could fail if you try to pack too much
in.  Having just looked at the Korn shell source, it appears that there is no
inherent limit - new variables are malloc'd.  Without looking at the Bourne
shell source, I would guess it is similar.

#(2) As I see it, the secret to writing interactive programs in shell script
#is to reduce disk access time to a minimum.  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?  As usual, the sh
#documentation gives no example.  Well, perhaps for this command no
#documentation should be needed -- but I've "time"d scripts with and 
#without use of this command and found no execution time difference.
#Comments?
There are a couple of possible reasons for seeing no difference when timing:
1. The non-builtin programs called are already in memory so no disk access
   is necessary
2. The hashing took place earlier and so was in effect both times.  Did you
   do "hash -r" in between?
There are many other variables that come into play here that will distort
the results of "time".

#P.S. I've got access to a korn shell.  How transportable are bourne scripts
#and is korn sufficiently more advanced (as a programming language) to make
#it worth my while to switch?
Definitely yes!  
Here are a few of the things I really love:
1. command line editing with either emacs or vi
2. built-in math evaluation - replaces expr very nicely
3. additional command substitution formats that take the place of calling
   "sed", "awk" and/or "basename" in most cases
3. it's faster all the way around
4. aliases
5. an environment file that goes with you wherever you go

As to "transportability", I think most anything you would write for the
Bourne shell will run (and run faster) in ksh.  I find ksh to be a complete
superset of standard sh.  While the rest of my attempts to answer your 
questions may (and likely do) have some errors, I am an ardent supporter
of shell programming and of the Korne shell.

Just my $ 0.02 worth.
L. Mark Larsen
lml@atlas.ATT.COM
att!atlas!lml