On 20.04.2021 13:08, Janis Papanagnou wrote:
> On 20.04.2021 07:18, Kenny McCormack wrote:
>> In article <s5la58$2ok$1@news-1.m-online.net>,
>> Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
>>>
>>> Is there an equally simple way to _interrogate_ the window title by
>>> a shell command?
>>
>> xdotool getactivewindow getwindowname
>>
>> should do it (at least as long as the calling window is the active window.
>
> I'll try incorporating that tool. Thanks!

In a specific scenario I noticed a corrupting effect when using this
code

xdotool getactivewindow getwindowname >"${HOME}/.sh_title_${TTYNR}"

in a shell function in .kshrc that is triggered by a trap on EXIT.

When I use a shell escape from some programs that allow that (often by
using a '!' as escape command), like vim or nethack (ksh->nethack->ksh),
then an exit from the innermost shell instance will hang (in case of an
escape from nethack) or corrupt the I/O (in case of an escape from vim).
What could be the reason for that effect?

(What works fine is a plain shell instance nesting, ksh->ksh->ksh.)

Janis

On Sat, 1 May 2021 04:11:44 +0200
Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
> In a specific scenario I noticed a corrupting effect when using this
> code
>
> xdotool getactivewindow getwindowname >"${HOME}/.sh_title_${TTYNR}"
>
> in a shell function in .kshrc that is triggered by a trap on EXIT.
>
> When I use a shell escape from some programs that allow that (often by
> using a '!' as escape command), like vim or nethack (ksh->nethack->ksh),
> then an exit from the innermost shell instance will hang (in case of an
> escape from nethack)

Is it the inner ksh which hangs or nethack ? Does file
"${HOME}/.sh_title_${TTYNR}" get written ?

> or corrupt the I/O (in case of an escape from vim).
> What could be the reason for that effect?

What does "corrupt the I/O" mean ?

> (What works fine is a plain shell instance nesting, ksh->ksh->ksh.)

In both situations what happens if the xdotool ... command is not part
of a trap ? For example what happens if from nethack or vim you call
something like

#!/usr/bin/ksh

xdotool getactivewindow getwindowname >"${HOME}/.sh_title_${TTYNR}"

?

On 01.05.2021 09:19, Spiros Bousbouras wrote:
> On Sat, 1 May 2021 04:11:44 +0200
> Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
>> In a specific scenario I noticed a corrupting effect when using this
>> code
>>
>> xdotool getactivewindow getwindowname >"${HOME}/.sh_title_${TTYNR}"
>>
>> in a shell function in .kshrc that is triggered by a trap on EXIT.
>>
>> When I use a shell escape from some programs that allow that (often by
>> using a '!' as escape command), like vim or nethack (ksh->nethack->ksh),
>> then an exit from the innermost shell instance will hang (in case of an
>> escape from nethack)
>
> Is it the inner ksh which hangs or nethack ? Does file
> "${HOME}/.sh_title_${TTYNR}" get written ?

(I'll reinstall the code and check that.)

>> or corrupt the I/O (in case of an escape from vim).
>> What could be the reason for that effect?
>
> What does "corrupt the I/O" mean ?

On returning from the '!'-shell session back into vim I cannot edit the
file any more. Every keystroke creates sequences of control characters
(bold-face light blue codes) it seems. It is still possible to type :q!
and leave vim (but I don't see the typed characters but something else).

>> (What works fine is a plain shell instance nesting, ksh->ksh->ksh.)
>
> In both situations what happens if the xdotool ... command is not part
> of a trap ? For example what happens if from nethack or vim you call
> something like
>
> #!/usr/bin/ksh
>
> xdotool getactivewindow getwindowname >"${HOME}/.sh_title_${TTYNR}"
>
> ?

I'm not sure what you suggest here. Do you mean to invoke that call
using the '!cmd' mechanism, or to create an executable shebang file
and call that from within the tools? (I'll try the latter.)

Janis

On Sat, 1 May 2021 09:47:51 +0200
Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
> On 01.05.2021 09:19, Spiros Bousbouras wrote:
> > On Sat, 1 May 2021 04:11:44 +0200
> > Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
> >> In a specific scenario I noticed a corrupting effect when using this
> >> code
> >>
> >> xdotool getactivewindow getwindowname >"${HOME}/.sh_title_${TTYNR}"
> >>
> >> in a shell function in .kshrc that is triggered by a trap on EXIT.
> >>
> >> When I use a shell escape from some programs that allow that (often by
> >> using a '!' as escape command), like vim or nethack (ksh->nethack->ksh),
> >> then an exit from the innermost shell instance will hang (in case of an
> >> escape from nethack)
> >
> > Is it the inner ksh which hangs or nethack ? Does file
> > "${HOME}/.sh_title_${TTYNR}" get written ?
>
> (I'll reinstall the code and check that.)
>
> >> or corrupt the I/O (in case of an escape from vim).
> >> What could be the reason for that effect?
> >
> > What does "corrupt the I/O" mean ?
>
> On returning from the '!'-shell session back into vim I cannot edit the
> file any more. Every keystroke creates sequences of control characters
> (bold-face light blue codes) it seems. It is still possible to type :q!
> and leave vim (but I don't see the typed characters but something else).

Does vim run on a terminal emulator ? If yes then likely what is happening
is that the ksh instance you invoke from within vim somehow changes the
settings of the terminal driver and vim doesn't know about it. Try running
a graphical vim (i.e. one which opens its own X Windows window) and invoke
ksh from that.

> >> (What works fine is a plain shell instance nesting, ksh->ksh->ksh.)
> >
> > In both situations what happens if the xdotool ... command is not part
> > of a trap ? For example what happens if from nethack or vim you call
> > something like
> >
> > #!/usr/bin/ksh
> >
> > xdotool getactivewindow getwindowname >"${HOME}/.sh_title_${TTYNR}"
> >
> > ?
>
> I'm not sure what you suggest here. Do you mean to invoke that call
> using the '!cmd' mechanism, or to create an executable shebang file
> and call that from within the tools? (I'll try the latter.)

I meant create an executable , say /pahtname/test , with content

#!/usr/bin/ksh
xdotool getactivewindow getwindowname >"${HOME}/.sh_title_${TTYNR}"

and from within vim or nethack do !/pahtname/test .

> On 01.05.2021 09:19, Spiros Bousbouras wrote:
>> On Sat, 1 May 2021 04:11:44 +0200
>>
>> Is it the inner ksh which hangs or nethack ? [...]

I haven't yet checked it, but I just recalled that the shell
had consumed significantly more CPU% than to be expected, so
I suppose it was the shell that hung.

Janis

On 01.05.2021 09:19, Spiros Bousbouras wrote:
>
> In both situations what happens if the xdotool ... command is not part
> of a trap ? For example what happens if from nethack or vim you call
> something like
>
> #!/usr/bin/ksh
>
> xdotool getactivewindow getwindowname >"${HOME}/.sh_title_${TTYNR}"
>
> ?

From vim I can call that command in a file abc by :r!abc or by :!abc
without issues, a .sh_title_x file will be written. From nethack I can
only start a shell instance by the !-command and can then call that abc
executable script without issues. No side effects with both cases.

So I suppose the issue is something odd with the .kshrc contents

function save_terminal_context
{
pwd > "${HOME}/.sh_pwdstat_${TTYNR}"
# xdotool getactivewindow getwindowname > "${HOME}/.sh_title_${TTYNR}"
}

trap 'save_terminal_context' EXIT

Janis