On Tue, 2005-05-24 at 19:03, Ralf Corsepius wrote:
> > Well, since I started this never-ending thread, maybe I can introduce a new,
> > but very related question to my original -
> > Given that my original question had to with generating a script/program to add
> > a number to the end of the number part of a long series of file names that
> > included both a number and a descriptive, and since I see that there were
> > many different approaches to solving this little problem, all of which were
> > way above my head, I would like to tackle one language and start learning
> > some programming/scripting skills. So, if you guys had it to start all over,
> > and were essentially rank beginners, which language would you tackle first?
>
> "sh" aka "shell" and the standard (POSIX) tools underneath.
>
> As I see it, these form "the standard toolbox" to solve such kind of
> problems, comparable to your "mechanical toolbox", containing screw
> drivers, screw wrenches, files and saws etc., you probably have at home
> to solve "standard home problems".
Some notes about this: first, the shell parses all your command line
input to begin with, so the same tricks of variable substitution,
i/o redirection, piping, and loop construction that can speed
command line operations are also exactly what you need to know for
scripting - just put the same input in a file to run again, perhaps
with variable substitution for the part that will be different next
time. Bourne shell syntax hasn't changed in 20+ years, so unlike just
about any other program, anything you wrote in that timespan is pretty
likely to just copy over to any unix-like box and work as-is. Going
forward, the bash extensions are also likely to be available. Since
everything uses the shell, it tends to be very stable. In fact a
typical use is to run a script as a wrapper to restart buggy programs
in compiled languages that are likely to crash (often because the
programmer thought it was a good idea to write his own input parser but
got it wrong). The 'tools' mentioned above started with a set of
programs included in unix from the start like sed, grep, awk, cut,
tr, expr, paste, sort, etc. that are each intended to to do one thing
well and to read from stdin, write to stdout so as to work well in
pipelines. In a typical shell script, these utilities do virtually all
the work and the shell is just glue that passes them the right options.
However, back when these concepts were being developed, it was pretty
easy to read *all* the unix man pages and understand which tool should
be used for which job. Before X was included, the entire manual set for
a unix system fit in 3 fairly small books. Now, with all the X programs
and development tools included, finding the old simple utilities would
be a much harder job even though they still work as well as ever.
Before you start something really complicated in a shell script, though,
you should think through whether it would be better in a more
comprehensive language like perl. In shell, you have extra overhead
of starting other programs for each operation. This is done very
efficiently but still is extra work compared to built-in operations, and
there are some operations like working with sockets that are included
in perl but not sh.
--
Les Mikesell
lesmikesell@xxxxxxxxx
