Cover V10, I05
Article

may2001.tar


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