Dave Wade wrote:
Jack,
For most "UNIX" commands (and many other features of UNIX) the man
pages are a great reference. However I don't actually find the ones
for sh useful when I am trying to write new shell scripts. I have just
written a script on Solaris to FTP several files to a remote host and
frankly the man pages were absolutely useless for this.
FTP doesn't automate well without some special program, as all you VM
guys found out
over the years. The question of, "Can a command execute, its output be
parsed, its return
code examined, and decision be made" this is all very simple. In
Mainframe Land you've
got special FTP things to hook to Rexx. Unix had those but mostly now
has Perl (and, lately,
the important language Ruby you musn't miss in the future) with library
FTP functions.
Shell programmers learn by reading the hundreds of scripts that already
exist on any Unix
system. Shell scripts are like zombies in a cheap horror film, they pop
up as part of everything.
The *sh* questions come mostly in three categories:
1. How do variables expand?
2. How do metacharacters such as* ' " ! | ` ; & * *affect the parsing
of a command line?
3. How does flow control work? with the subissue:
1. How does the Unix command *test* work (linked to the
single-char command name *[* on most systems!!)
This is all there is that can be handled portably in sh, with the
exception that modern ones also offer
*function {
# ...
}*
definitions. The rest is knowing Unix commands well and how to pipe
them. If you haven't a good
familiarity with Unix commands themselves, and with Unix command-line
pipes, *sh* itself isn't much use!
Anyway, at least once read the man page for *sh* from beginning to end,
_/then/_ go looking for help resources. It's
us Unix weenies who invented the M-A-G-I-C A-C-R-O-N-Y-M :::
RTFM
:-)
--
Jack J. Woehr # "Self-delusion is
http://www.well.com/~jax # half the battle!"
http://www.softwoehr.com # - Zippy the Pinhead
