• Difference between launch methods

    From Frank Winkler@21:1/5 to All on Wed Jul 6 10:53:28 2022
    Hi there !

    I have a couple of completely different ksh scripts (#!/bin/ksh) which sometimes behave differently depending on whether I call them directly
    by "<script>" or by "ksh <script>" (from an interactive bash). It's the
    same ksh binary in both cases.

    To my understanding, roughly the same things should happen. In the
    latter case, is one more shell started? Is the first ksh replaced by the
    one from inside the script? Actually, it seems that some comparisons do different things in both cases and it looks like the second call mostly
    does what is expected. I can see the issue on Solaris and on macOS.

    Any hints?

    fw

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ed Morton@21:1/5 to Ed Morton on Wed Jul 6 06:11:44 2022
    On 7/6/2022 6:09 AM, Ed Morton wrote:
    On 7/6/2022 3:53 AM, Frank Winkler wrote:
    Hi there !

    I have a couple of completely different ksh scripts (#!/bin/ksh) which
    sometimes behave differently depending on whether I call them directly
    by "<script>" or by "ksh <script>" (from an interactive bash). It's
    the same ksh binary in both cases.

    To my understanding, roughly the same things should happen. In the
    latter case, is one more shell started? Is the first ksh replaced by
    the one from inside the script? Actually, it seems that some
    comparisons do different things in both cases and it looks like the
    second call mostly does what is expected. I can see the issue on
    Solaris and on macOS.

    Any hints?

         fw


    Maybe the `ksh` that's first in your PATH (and so invoked when you call
    ksh on the command line) isn't `/bin/ksh`, maybe it's some other version
    of ksh (ksh88, ksh93, mksh, pdksh, etc.). Try `ksh --version` and
    `/bin/ksh --version` or whatever your ksh version supports to identify
    itself to see if they're different. Without a minimal code sample that
    can reproduce the problem it's hard to guess at what else might be an
    issue.

        Ed.

    Ignore that, I see now you said it is the same binary and the script
    contains a shebang so what I described can't be the issue. Provide a
    MINIMAL code sample that can reproduce the problem and tell us in what
    way the behavior differs.

    Ed.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Josef Moellers@21:1/5 to Frank Winkler on Wed Jul 6 12:55:07 2022
    On 06.07.22 10:53, Frank Winkler wrote:
    Hi there !

    I have a couple of completely different ksh scripts (#!/bin/ksh) which sometimes behave differently depending on whether I call them directly
    by "<script>" or by "ksh <script>" (from an interactive bash). It's the
    same ksh binary in both cases.

    To my understanding, roughly the same things should happen. In the
    latter case, is one more shell started? Is the first ksh replaced by the
    one from inside the script?

    No.
    When you run the script as a command, then the kernel checks for the
    shebang ("#!") and then runs the binary given, "/bin/ksh" in this case,
    giving it the script as a parameter. ksh will then ignore the first line
    as it is a comment.
    When you explicitly run the script through ksh, then the first line is
    just a comment and ignored by ksh just like above.

    Actually, it seems that some comparisons do
    different things in both cases and it looks like the second call mostly
    does what is expected. I can see the issue on Solaris and on macOS.

    Any additional answer requires my crystal ball which is currently out of
    order, awaiting spare parts from some Russian old lady ;-)

    Josef

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ed Morton@21:1/5 to Frank Winkler on Wed Jul 6 06:09:47 2022
    On 7/6/2022 3:53 AM, Frank Winkler wrote:
    Hi there !

    I have a couple of completely different ksh scripts (#!/bin/ksh) which sometimes behave differently depending on whether I call them directly
    by "<script>" or by "ksh <script>" (from an interactive bash). It's the
    same ksh binary in both cases.

    To my understanding, roughly the same things should happen. In the
    latter case, is one more shell started? Is the first ksh replaced by the
    one from inside the script? Actually, it seems that some comparisons do different things in both cases and it looks like the second call mostly
    does what is expected. I can see the issue on Solaris and on macOS.

    Any hints?

        fw


    Maybe the `ksh` that's first in your PATH (and so invoked when you call
    ksh on the command line) isn't `/bin/ksh`, maybe it's some other version
    of ksh (ksh88, ksh93, mksh, pdksh, etc.). Try `ksh --version` and
    `/bin/ksh --version` or whatever your ksh version supports to identify
    itself to see if they're different. Without a minimal code sample that
    can reproduce the problem it's hard to guess at what else might be an issue.

    Ed.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Janis Papanagnou@21:1/5 to Frank Winkler on Wed Jul 6 14:21:45 2022
    On 06.07.2022 10:53, Frank Winkler wrote:
    Hi there !

    I have a couple of completely different ksh scripts (#!/bin/ksh) which sometimes behave differently depending on whether I call them directly
    by "<script>" or by "ksh <script>" (from an interactive bash). It's the
    same ksh binary in both cases.

    Yes, there can be differences; for example the first expansion of "$_"
    will contain a different value.

    If started from a bash context the environment settings may contribute
    to differences.

    But it would be more important to tell us what difference you observe.


    To my understanding, roughly the same things should happen. In the
    latter case, is one more shell started? Is the first ksh replaced by the
    one from inside the script? Actually, it seems that some comparisons do different things in both cases and it looks like the second call mostly
    does what is expected. I can see the issue on Solaris and on macOS.

    Any hints?

    (Just to be sure; verify the versions used.)

    Janis

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Frank Winkler@21:1/5 to Ed Morton on Wed Jul 6 14:31:45 2022
    On 06.07.2022 13:11, Ed Morton wrote:

    >Ignore that, I see now you said it is the same binary and the script
    >contains a shebang so what I described can't be the issue. Provide a
    >MINIMAL code sample that can reproduce the problem and tell us in what
    >way the behavior differs.

    I'll do but I think I'll first have to find out what exactly "it doesn't
    work" means, i.e. the exact line(s) where the difference occurs. This
    will require some tests but should be easy to do. Please stay tuned ...

    TIA

    fw

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Kaz Kylheku@21:1/5 to Frank Winkler on Wed Jul 6 18:59:15 2022
    On 2022-07-06, Frank Winkler <usenet@f.winkler-ka.de> wrote:
    Hi there !

    I have a couple of completely different ksh scripts (#!/bin/ksh) which sometimes behave differently depending on whether I call them directly
    by "<script>" or by "ksh <script>" (from an interactive bash). It's the
    same ksh binary in both cases.

    Is it the same binary?" #!/bin/ksh specifies the absolute path; whereas
    ksh <script> searches.

    Moreover if <script> is a simple name containing no slash, and "." isn't
    in the PATH, then <script> and ksh <script> are different. <script>
    searches through PATH, whereas ksh <script> runs the script found
    in the current directory.

    Thus, make sure you're comparing these:

    ./<script>
    /bin/ksh <script>

    --
    TXR Programming Language: http://nongnu.org/txr
    Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Frank Winkler@21:1/5 to Kaz Kylheku on Thu Jul 7 09:32:28 2022
    On 06.07.2022 20:59, Kaz Kylheku wrote:

    > hus, make sure you're comparing these:
    >
    > ./<script>
    > /bin/ksh <script>
    >

    Thanks for the hint but in fact, I did. Of course, I have "./<script>"
    and I forgot to type it correctly. Sorry for the confusion.

    Regards

    fw

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Frank Winkler@21:1/5 to Frank Winkler on Thu Jul 21 14:04:33 2022
    On 06.07.2022 14:31, Frank Winkler wrote:

    >I'll do but I think I'll first have to find out what exactly "it doesn't
    >work" means, i.e. the exact line(s) where the difference occurs. This
    >will require some tests but should be easy to do. Please stay tuned ...

    Just to prevent you from thinking I lost track: I still wasn't able to
    find the piece of code that causes the actual difference in behavior but
    I'll keep trying ...

    Regards

    fw

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Frank Winkler@21:1/5 to All on Thu Jul 21 15:47:16 2022
    On 06.07.2022 14:31, I wrote:

    >I'll do but I think I'll first have to find out what exactly "it
    >doesn't work" means, i.e. the exact line(s) where the difference
    >occurs. This will require some tests but should be easy to do. Please
    >stay tuned ...

    Just to prevent you from thinking I lost track: I still wasn't able to
    find the piece of code that causes the actual difference in behavior but
    I'll keep trying ...

    Regards

    fw

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Janis Papanagnou@21:1/5 to Frank Winkler on Thu Jul 21 18:19:36 2022
    On 21.07.2022 15:47, Frank Winkler wrote:
    On 06.07.2022 14:31, I wrote:

    I'll do but I think I'll first have to find out what exactly "it
    doesn't work" means, i.e. the exact line(s) where the difference
    occurs. This will require some tests but should be easy to do. Please
    stay tuned ...

    Just to prevent you from thinking I lost track: I still wasn't able to
    find the piece of code that causes the actual difference in behavior but
    I'll keep trying ...

    Have you added a set -x command to the script and compared the output
    line by line?

    Janis


    Regards

    fw


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)