stever@tree.UUCP (Steve Rudek) (10/15/88)
Although I've got access to a number of books on shell programming, I've yet to find any rigorous, comprehensive text on shell programming; that would be okay if I could even find an excellent *combination* of texts. _The UNIX Programming Environment_, by Kernighan and Pike, is a very good book but it is not *nearly* comprehensive enough (for example, it only mentions the "eval" command in a "Hint" and it doesn't discuss named procedures at all!). 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 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. Anyway, enough of that; I actually wanted to ask a couple of questions! (1) I'm making extensive use of *very long* environment strings (using expr to build and strip them of "field" information). I'm also using lots of named procedures and, in some occasions, calling them *recursively* (neat trick, that!). 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? (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? 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?
lml@cbnews.ATT.COM (L. Mark Larsen) (10/16/88)
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!lmlhenry@utzoo.uucp (Henry Spencer) (10/16/88)
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
lvc@cbnews.ATT.COM (Lawrence V. Cipriani) (10/18/88)
In article <120@tree.UUCP> stever@tree.UUCP (Steve Rudek) writes: >Although I've got access to a number of books on shell programming, I've >yet to find any rigorous, comprehensive text on shell programming; that >would be okay if I could even find an excellent *combination* of texts. Get "The Kornshell Command and Programming Language" by Morris I. Bolsky and David G. Korn. The book is published by Prentice Hall, ISBN 0-13-516972-0. It is very rigorous, and comprehensive. I don't know how much it costs, I got mine free. I like it a lot, but take that with a grain of salt, since I read the thing many times as one of the draft reviewers. I did gave away all my other shell books when I got it. -- Larry Cipriani, AT&T Network Systems, Columbus OH, cbnews!lvc lvc@cbnews.ATT.COM