On Mon, Apr 30, 2012 at 7:20 PM, David Korn <[email protected]> wrote:
> cc: [email protected]
> Subject: Re: [ast-users] techniques for building ksh libraries?
> --------
>
>> is there anywhere i can find info on ways people build up ksh script
>> libraries?
>> i'm thinking of things like standardizing parameter parsing, error handling,
>> log
>> ging, other utility functions, etc. across a family of dozens of scripts.
>>
>> i'd also be interested in any commentary on "best practices" (if you'll
>> forgive
>> the jargon)--should i write everything with "set -eu" turned on, when is a
>> "()"
>> function preferred (or required!) over a "function" function, when to use
>> namere
>> fs, etc.
>> --
>> Aaron Davies
>> [email protected]
>
> I don't have any document on this. Maybe someone else has one.
>
> Here are a few suggestions:
>
> 1. Uset getopts for option parsing. Also, use the extension to getopts
> that generate man pages as well. getopts --man describes the format
> and there are several shell scripts shipped with ksh93 that can
> be use as examples.
Erm... for less complex functions it is useful just to pass a compound
variable via nameref as argument. That saves the "getopts" overhead.
> 2. Use function name, rather than name() whenever you have local
> variables or traps that need scoping. name() is slightly faster
> than function name since it doesn't need to do scoping.
>
> 3. I use -eu for debugging.
>
> 4. In most cases, setting IFS='' is better than the default since
> $x won't get split. You rarely want splitting except for read
> and set. read can be handled with IFS=<delim> read ...
> Set requires saving and restoring IFS.
>
> 5. name references are usually used to pass variables by reference.
> However, they are also useful for references withing compound
> variables. They can also be used in for loops to go through
> a list of variables.
>
> 6. Used [[...]] rather than test or [...].
>
> 7. Use ((...)) for arithmetic rather than let.
>
> 8. Use -- to end command options to prevent the first argument to
> be treated as an option.
>
> 9. Use trap on EXIT to clean up files for unexpected failures.
>
> 10. Instead of
> while read -r
> do ...
> done
> use
> while read -u$n -r
> do ...
> done {n}<&-
> which runs much faster when reading from a pipe since it can
> do read-ahead with buffered reads.
>
> I welcome people to submit other suggestions as well.
11. Do not use global variables (or other global resouces). If you
need global variables to keep a state across multiple calls either use
a comound variable maintained by the caller as "context" or "typeset
-S varname" ("-S" means |static|, more or less like the ISO C99
definition of |static|. Hint: The -S option of "typeset" works with
almost all combinations of "typeset", e.g. "integer -S varname",
"float -S varname", "compound -S varname" or "typeset -S -a varname"
work).
12. Do not use fixed fd numbers (like "exec 5<>/etc/profile"). Use
"redirect {n}<>/etc/profile" instead ("redirect" is an alias for
"command exec" (if "exec" fails it will abort the whole script...
putting the "command" in front makes "exec" just return like a normal
builtin) and the "{n}" assigns a new fd number dynamically and puts
them into the integer variable "n").
Uhm... AFAIK once I had a more complete list about function libraries
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [email protected]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
_______________________________________________
ast-users mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-users
