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

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

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.

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.

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

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

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

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

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

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

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
>