|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"|
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