JP Vossen on 21 Feb 2011 14:08:50 -0800


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[PLUG] Fwd: Re: ... "Bash 101: Intro to Shell Scripting"


Cross-post of a thread between Fred, some folks he works with, and I that may be of use for the list.

On 02/20/2011 11:48 PM, Fred Stluka wrote:
Team,

Here are JP's slides for the bash talk tomorrow night. I just
read through them. Good stuff!
http://www.jpsdomain.org/public/2011_bash_101.pdf

...this is EXACTLY all the stuff we are currently
teaching ourselves about how to write a bash function library,
how to return strings from functions, etc. Take good notes!

Mmmmm, kind of. Functions and libraries are a little more advanced than
"bash 101" so I really won't cover them, except that they exist.

However, Chapter 10 of the _bash Cookbook_, especially these, will be of
interest:

10.2 "Reusing Code with Includes and Sourcing"
10.4 "Defining Functions"
10.5 "Using Functions: Parameters and Return Values"
and 19.8 "Forgetting That Pipelines Make Subshells"

You will also want to be aware of the resources in
http://www.bashcookbook.com/bashinfo/, especially sections like
http://www.bashcookbook.com/bashinfo/#examples/functions.

As I've mentioned before, the bash source contains a ton of great info,
but no one ever sees it anymore, so I annotated it and put it out there
to get it indexed in search engines.


As for shell code libraries, there are 2 basic ways to organize them:
monolithic or individual. Which way to go partly depends on your coding
philosophies and what you do in other languages.

One thing to keep in mind that is that bash doesn't give you an easy way
to source only certain functions, the way Perl does. bash is "all or
nothing", so a long monolithic library file sourced to use just 1
function may slow things down.

One way around that is to write your library as individual files (or
small groups of related functions per file), then write meta files that
do nothing but source all or groups of function files. They you can
balance the speed of picking only what you need against the tedium of
having to source 35 files for complicated scripts. More work up-front
and to maintain, but more flexible.

Search inside page http://www.bashcookbook.com/bashinfo/ for 'library'
(ignore the readline hits), and 'autoload'.


Another thing is that, as noted in 10.5, to get values back out of a
bash function you either use GLOBAL variables or command substitution,
both of which can get ugly fast.

Using and changing GLOBAL variables from functions is easy enough to do
and understand, but as you can probably see how it gets ugly fast in a
"library" environment.

Using command substitution is more programmatically sound, but gets
clunky fast. It works well with a scalar return value:
	answer=$(my_func "$foo" "$bar" "$baz")
But not so well otherwise since you have to turn around and parse the
return value.

Later,
JP
----------------------------|:::======|-------------------------------
JP Vossen, CISSP            |:::======|      http://bashcookbook.com/
My Account, My Opinions     |=========|      http://www.jpsdomain.org/
----------------------------|=========|-------------------------------
"Microsoft Tax" = the additional hardware & yearly fees for the add-on
software required to protect Windows from its own poorly designed and
implemented self, while the overhead incidentally flattens Moore's Law.
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug