New
Messages
To: Rainer Raab
From: Michael Wang <mwang@mindspring.com>
Subject: Your article on ksh functions (March issue)
I read the introduction and conclusion part on your article on
ksh functions, as I am interested to know why you choose to use
*functions* instead of the scripts. However, I fail to get the answer.
Can you give me three reasons?
As to the two function forms:
funtion name { ... }
and
name() { ... }
the primary difference has to do with scoping of variables and traps,
as documented in Bolsky and Korn, ISBN 0-13-182700-6, page 76.
To: Michael Wang <mwang@mindspring.com>
Subject: Re: Your article on ksh functions
Hello Michael,
Great question. Creating globally accessible Korn shell function
libraries provides the same benefits as providing the same libraries
as Korn shell scripts, i.e. promoting the sharing of code, decreasing
the amount of time spent QA'ing scripts, and reducing redundant
programming.
As to why do I prefer using globally accessible Korn Shell functions
instead of implementation as a Korn Shell script:
1. Functions run as part of the current shell, i.e. they behave
as built-in shell commands. They don't run as a separate process.
2. Functions have order precedence over scripts when invoked,
providing for enhanced security.
3. Functions can be more easily secured by the use of the FPATH
environment variable, as opposed to using the PATH environment variable.
4. Once a function has been accessed, it is stored in memory and
does not have to been re-read from disk.
5. Functions provide a standardized framework to build on, rather
than creating and enforcing your own standards.
6. Functions can be easily managed using the built-in functions
(typeset -f) command to display available functions.
I hope that answers your question.
Best Regards,
Rainer Raab
To: Brett Lymn
From: Alek Komarnitsky <alek@komar.org>
Subject: Comment on "Duplicating Data" article in March/2001
Sys Admin
Brett,
I read your article about "Duplicating Data", and you
talked about a handy feature in Solaris2.6+ where the automounter
now has the ability (as amd has had for a long time) to failover
to server2 if server1 goes down (after the mount occurs).
I'm pretty sure you need to have the mount point specified
as read-only ... this kinda clues in the automounter that this is
a "replicated filesystem" and it can therefore assume
you have done "something" to ensure that they are all
the same (as you correctly talk about later in your article).
The "ro" option exists in your discussion about
amd; but wasn't there for the Sun automounter, so maybe
this was just an editing blip?
alek@komar.org
From: Brett Lymn
Subject: Re: Duplicating Data article in March
Yes, you are correct. There should have been a "-ro"
option on the example for the Sun automounter. I have it in my test
setup but, for some reason, it never made it into the article. The
correct line should read:
tree -ro server1:/share/file/tree server2:/share/file/tree
Thanks for being so observant.
Brett Lymn
Computer Systems Administrator
BAE SYSTEMS
|