Printable View
who can explain the following?
lorenz 11% cd /var/tmp
lorenz 12% cat > qq
#!/bin/ksh
SELF="$0"
echo $SELF
$SELF
lorenz 13% chmod a+x qq
lorenz 14% ./qq|head -3
lorenz 15% `pwd`/qq|head -3
/var/tmp/qq
lorenz 16%
Is this a bug in an old ksh. Tried it on a recent imac and there it
yields /var/tmp/qq three times, as it does when using /bin/sh.
--
Georg Schwarz [url]http://home.pages.de/~schwarz/[/url]
[email]georg.schwarz@freenet.de[/email] +49 178 8545053
Georg Schwarz wrote:[color=blue]
> who can explain the following?
> lorenz 11% cd /var/tmp
> lorenz 12% cat > qq
> #!/bin/ksh
> SELF="$0"
> echo $SELF
> $SELF
> lorenz 13% chmod a+x qq
> lorenz 14% ./qq|head -3
> lorenz 15% `pwd`/qq|head -3
> /var/tmp/qq
> lorenz 16%[/color]
[color=blue]
> Is this a bug in an old ksh. Tried it on a recent imac and there it
> yields /var/tmp/qq three times, as it does when using /bin/sh.[/color]
The fundamental limitation on recursive functions is the
amount of stack space allocated to the process. In a
previous post I determined that similar IRIX ksh(1) test
script demonstrated a recursive depth of 66 levels before
stack space ran out:
[url]http://groups.google.com/group/comp.unix.shell/browse_thread/thread/7ead8ca476370ad5/d676988035407066?lnk=st&q=IRIX+group%3Acomp.unix.shell+author%3Absh20858%40&rnum=19&hl=en#d676988035407066[/url]
So my surprise is not that the numbers are different
(because each host will have different limits preset),
but that they are so small -- so much so that I wonder
if I am correct in my presumption of the basic mechanism
for failure being stack ulimits.
The prompt indicates that you are invoking ksh(1)
via your t/csh(1) interactive shell -- for which its
"limit" builtin _presumably_ sets the same Unix
ulimits via the same system call mechanism as
would have been set by the equivalent ksh(1)
"ulimit" builtin, _but_ it is not good to second-guess
csh(1) and even tcsh(1). Are your values different for
testing under a ksh(1) interactive shell?
That said, what are your values under different
stackspace limits configured by:
# in t/csh(1):
limit stacksize
limit -h stacksize
# in ksh(1):
ulimit -Ss
ulimit -Hs
.... and what does increasing the [soft] limit do
to the output result?
[color=blue]
> Georg Schwarz [url]http://home.pages.de/~schwarz/[/url][/color]
I looked at your links web page and (just out of curiosity)
wanted to ask how it is possible that you write in perfect,
colloquial English? Did you study in America or England?
=Brian
Georg Schwarz wrote:[color=blue]
> who can explain the following?
> lorenz 11% cd /var/tmp
> lorenz 12% cat > qq
> #!/bin/ksh
> SELF="$0"
> echo $SELF
> $SELF
> lorenz 13% chmod a+x qq
> lorenz 14% ./qq|head -3
> lorenz 15% `pwd`/qq|head -3
> /var/tmp/qq
> lorenz 16%[/color]
[color=blue]
> Is this a bug in an old ksh. Tried it on a recent imac and there it
> yields /var/tmp/qq three times, as it does when using /bin/sh.[/color]
The fundamental limitation on recursive functions is the
amount of stack space allocated to the process. In a
previous post I determined that similar IRIX ksh(1) test
script demonstrated a recursive depth of 66 levels before
stack space ran out:
[url]http://groups.google.com/group/comp.unix.shell/browse_thread/thread/7ead8ca476370ad5/d676988035407066?lnk=st&q=IRIX+group%3Acomp.unix.shell+author%3Absh20858%40&rnum=19&hl=en#d676988035407066[/url]
So my surprise is not that the numbers are different
(because each host will have different limits preset),
but that they are so small -- so much so that I wonder
if I am correct in my presumption of the basic mechanism
for failure being stack ulimits.
The prompt indicates that you are invoking ksh(1)
via your t/csh(1) interactive shell -- for which its
"limit" builtin _presumably_ sets the same Unix
ulimits via the same system call mechanism as
would have been set by the equivalent ksh(1)
"ulimit" builtin, _but_ it is not good to second-guess
csh(1) and even tcsh(1). Are your values different for
testing under a ksh(1) interactive shell?
That said, what are your values under different
stackspace limits configured by:
# in t/csh(1):
limit stacksize
limit -h stacksize
# in ksh(1):
ulimit -Ss
ulimit -Hs
.... and what does increasing the [soft] limit do
to the output result?
[color=blue]
> Georg Schwarz [url]http://home.pages.de/~schwarz/[/url][/color]
I looked at your links web page and (just out of curiosity)
wanted to ask how it is possible that you write in perfect,
colloquial English? Did you study in America or England?
=Brian
In article <1145321072.472209.60510@i40g2000cwc.googlegroups.com>,
bsh <brian_hiles@rocketmail.com> wrote:[color=blue]
>Georg Schwarz wrote:[color=green]
>> who can explain the following?[/color][/color]
[color=blue][color=green]
>> #!/bin/ksh
>> SELF="$0"
>> echo $SELF
>> $SELF[/color][/color]
[color=blue][color=green]
>> lorenz 14% ./qq|head -3
>> lorenz 15% `pwd`/qq|head -3
>> /var/tmp/qq
>> qq[/color][/color]
[color=blue]
>The fundamental limitation on recursive functions is the
>amount of stack space allocated to the process.[/color]
I believe that Georg was referring to the fact that $0 changes
from /var/tmp/qq to just plain qq which is an issue that would not
have anything to do with recursion limits.
Walter Roberson wrote:[color=blue]
> I believe that Georg was referring to the fact that $0 changes
> from /var/tmp/qq to just plain qq which is an issue that would not
> have anything to do with recursion limits.[/color]
Yes indeed. I am wrong _twice_, for expecting to have needed
now to have posted a followup to the effect that since functions
are not used, that issue "should" have been with the issue
of the value of NPROC instead of stack issues at all -- an issue
that I realized only after I pressed the "Send" button.... I must
read the OQ more carefully.
With the issue of $0 being truncated to its basename, could
it be that ksh(1) uses execvp(2) when non-interactive, and
execve(2) when not?
=Brian
Walter Roberson wrote:[color=blue]
> I believe that Georg was referring to the fact that $0 changes
> from /var/tmp/qq to just plain qq which is an issue that would not
> have anything to do with recursion limits.[/color]
Yes indeed. I am wrong _twice_, for expecting to have needed
now to have posted a followup to the effect that since functions
are not used, that issue "should" have been with the issue
of the value of NPROC instead of stack issues at all -- an issue
that I realized only after I pressed the "Send" button.... I must
read the OQ more carefully.
With the issue of $0 being truncated to its basename, could
it be that ksh(1) uses execvp(2) when non-interactive, and
execve(2) when not?
=Brian