.script nesting

[John Adams]

Thanks to Brian Hiles for the quick answer about typeset -p.

My question arose because I'm calling one script as a .command in
another script, and I'm concerned about unwanted interaction between the
scripts. Here's another question on that subject:

How deeply can I nest .commands. If scriptA calls .scriptB, which calls
.scriptC, all three scripts should have the same environment. But how
deep can I go? (No bumperstickers, please. ;-) )

John Adams
John....@BentonvilleAR.ncr.com

[Brian S Hiles]

John Adams (John....@BentonvilleAR.ncr.com) wrote:
: Thanks to Brian Hiles for the quick answer about typeset -p.

Hello again. I'm glad you found that my previous response wasn't more
verbose than perhaps something simple you meant to ask.

: My question arose because I'm calling one script as a .command in

: another script, and I'm concerned about unwanted interaction between the
: scripts. Here's another question on that subject:

: How deeply can I nest .commands. If scriptA calls .scriptB, which calls
: .scriptC, all three scripts should have the same environment. But how
: deep can I go? (No bumperstickers, please. ;-) )

I assume you mean ". command". The dot, as it is a command, needs to be
separated from its argument by whitespace. I also assume in the context
of the previous query you use ksh93.

Looking through my book, "The New Kornshell Command and Programming Language,"
I could find no reference to arbitrary limits referring to dot scripts.
However, there are two points to note:

(1) ksh93 can invoke a sourced script with arguments (like ksh88), but
ksh93 will _restore_ the original argv when finished. Thus, like
functions, stack space is used, and thus architecture and OS
dependent (sbrk, malloc) and user environment dependent (ulimit -s)
limitations wil apply.

(2) The entire dot script is read before any commands are executed.
Therefore if aliases, say, are set in one script, they won't be
available for use until the script has ended or another dot script
is sourced.

Now, a little experiment: in file testsource:

trap 'print $incr' ERR
let incr+=1
. testsource
--

Now, starting it off with command "incr=0 . testsource", the recursion
fails at a depth of 66 calls, on my system (IRIX 5.x)

-Brian
--
,---. ,---. ,---. ,---. ,---. ,---. ,---.
/ _ \ / _ \ / _ \ / _ \ / _ \ / _ \ / _ \
.' / \ `.' / mailto:bsh2...@challenger.atc.fhda.edu \ `.' / \ `.
__,' `.___,' `.___,' `.___,' `.___,' `.___,' `.___,' `.__

[user]

John Adams <John....@BentonvilleAR.ncr.com> wrote:

>Thanks to Brian Hiles for the quick answer about typeset -p.

>My question arose because I'm calling one script as a .command in

>another script, and I'm concerned about unwanted interaction between the
>scripts. Here's another question on that subject:

>How deeply can I nest .commands. If scriptA calls .scriptB, which calls
>.scriptC, all three scripts should have the same environment. But how
>deep can I go? (No bumperstickers, please. ;-) )

> John Adams
> John....@BentonvilleAR.ncr.com

I'm talking under correcting, but as far as I know it depends on your
environment. It is limited by certain parameters like MAXUP & NPROC on
3.2v4.2 and by your memory.

Jaco de Jager
sam...@global.co.za