bug in IRIX 5.3 ksh? - SGI

This is a discussion on bug in IRIX 5.3 ksh? - SGI ; 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 ../qq ../qq ../qq lorenz 15% `pwd`/qq|head -3 /var/tmp/qq qq qq lorenz 16% ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: bug in IRIX 5.3 ksh?

  1. bug in IRIX 5.3 ksh?

    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
    ../qq
    ../qq
    ../qq
    lorenz 15% `pwd`/qq|head -3
    /var/tmp/qq
    qq
    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 http://home.pages.de/~schwarz/
    georg.schwarz@freenet.de +49 178 8545053

  2. Re: bug in IRIX 5.3 ksh?

    Georg Schwarz wrote:
    > 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
    > ./qq
    > ./qq
    > ./qq
    > lorenz 15% `pwd`/qq|head -3
    > /var/tmp/qq
    > qq
    > 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.


    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:

    http://groups.google.com/group/comp....76988035407066

    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?

    > Georg Schwarz http://home.pages.de/~schwarz/


    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


  3. Re: bug in IRIX 5.3 ksh?

    Georg Schwarz wrote:
    > 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
    > ./qq
    > ./qq
    > ./qq
    > lorenz 15% `pwd`/qq|head -3
    > /var/tmp/qq
    > qq
    > 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.


    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:

    http://groups.google.com/group/comp....76988035407066

    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?

    > Georg Schwarz http://home.pages.de/~schwarz/


    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


  4. Re: bug in IRIX 5.3 ksh?

    In article <1145321072.472209.60510@i40g2000cwc.googlegroups.c om>,
    bsh wrote:
    >Georg Schwarz wrote:
    >> who can explain the following?


    >> #!/bin/ksh
    >> SELF="$0"
    >> echo $SELF
    >> $SELF


    >> lorenz 14% ./qq|head -3
    >> ./qq
    >> ./qq
    >> ./qq
    >> lorenz 15% `pwd`/qq|head -3
    >> /var/tmp/qq
    >> qq
    >> qq


    >The fundamental limitation on recursive functions is the
    >amount of stack space allocated to the process.


    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.

  5. Re: bug in IRIX 5.3 ksh?


    Walter Roberson wrote:
    > 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.


    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


  6. Re: bug in IRIX 5.3 ksh?


    Walter Roberson wrote:
    > 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.


    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


+ Reply to Thread