Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Get terminal/window title
128 views
Skip to first unread message
Janis Papanagnou
Apr 19, 2021, 9:18:36 PM4/19/21
to
With the standard shell terminal that I use on Ubuntu I can set the
window title. E.g. by using the GUI menu (Terminal-> Set Title...),
or by setting it with a shell command, e.g. with something like
echo -ne "\033]0;SOME TITLE HERE\007"
Is there an equally simple way to _interrogate_ the window title by
a shell command?
Janis
window title. E.g. by using the GUI menu (Terminal-> Set Title...),
or by setting it with a shell command, e.g. with something like
echo -ne "\033]0;SOME TITLE HERE\007"
Is there an equally simple way to _interrogate_ the window title by
a shell command?
Janis
Kaz Kylheku
Apr 19, 2021, 9:59:05 PM4/19/21
to
Yes and no. There is a ESC[21t sequence. It only works on xterm,
and a couple other terminals. It's considered a security hole, so
requires configuration to allow it. Some emulators give a canned answer
which is not actually the dynamic title.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Dan Espen
Apr 19, 2021, 10:08:42 PM4/19/21
to
Kaz Kylheku <563-36...@kylheku.com> writes:
> On 2021-04-20, Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>> With the standard shell terminal that I use on Ubuntu I can set the
>> window title. E.g. by using the GUI menu (Terminal-> Set Title...),
>> or by setting it with a shell command, e.g. with something like
>>
>> echo -ne "\033]0;SOME TITLE HERE\007"
>>
>> Is there an equally simple way to _interrogate_ the window title by
>> a shell command?
>
> Yes and no. See here: https://unix.stackexchange.com/a/482818/16369
>
> Yes and no. There is a ESC[21t sequence. It only works on xterm,
> and a couple other terminals. It's considered a security hole, so
> requires configuration to allow it. Some emulators give a canned answer
> which is not actually the dynamic title.
Rather than using an escape sequence, I can access the window title
> On 2021-04-20, Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>> With the standard shell terminal that I use on Ubuntu I can set the
>> window title. E.g. by using the GUI menu (Terminal-> Set Title...),
>> or by setting it with a shell command, e.g. with something like
>>
>> echo -ne "\033]0;SOME TITLE HERE\007"
>>
>> Is there an equally simple way to _interrogate_ the window title by
>> a shell command?
>
> Yes and no. See here: https://unix.stackexchange.com/a/482818/16369
>
> Yes and no. There is a ESC[21t sequence. It only works on xterm,
> and a couple other terminals. It's considered a security hole, so
> requires configuration to allow it. Some emulators give a canned answer
> which is not actually the dynamic title.
using xprop to retrieve WM_NAME. Not really sure what's going on under
the covers.
--
Dan Espen
Kenny McCormack
Apr 20, 2021, 1:18:45 AM4/20/21
to
In article <s5la58$2ok$1...@news-1.m-online.net>,
xdotool getactivewindow getwindowname
should do it (at least as long as the calling window is the active window.
In fact, it is kind of a weakness in xdotool, that there is no obvious way
to get information about the calling process's window; using
getactivewindow is a kludge, but it is likely to work in most cases.
Thinking about this some more, I suppose what you could do is:
# At the beginning...
# Then later on...
# set it to whatever you really want it to...
echo -ne "\033]0;whatever whatever probably dynamic\007"
# Then later on...
echo "My window title is: $(xdotool getwindowname $myWinId)"
--
I am not a troll.
Rick C. Hodgin
I am not a crook.
Rick M. Nixon
should do it (at least as long as the calling window is the active window.
In fact, it is kind of a weakness in xdotool, that there is no obvious way
to get information about the calling process's window; using
getactivewindow is a kludge, but it is likely to work in most cases.
Thinking about this some more, I suppose what you could do is:
# At the beginning...
echo -ne "\033]0;SOME TITLE HERE\007"
myWinId=$(xdotool search --only --sync --name "SOME TITLE HERE")
# Then later on...
# set it to whatever you really want it to...
echo -ne "\033]0;whatever whatever probably dynamic\007"
# Then later on...
echo "My window title is: $(xdotool getwindowname $myWinId)"
--
I am not a troll.
Rick C. Hodgin
I am not a crook.
Rick M. Nixon
Richard Harnden
Apr 20, 2021, 6:07:59 AM4/20/21
to
Janis Papanagnou
Apr 20, 2021, 7:08:31 AM4/20/21
to
On 20.04.2021 07:18, Kenny McCormack wrote:
> In article <s5la58$2ok$1...@news-1.m-online.net>,
> Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>> With the standard shell terminal that I use on Ubuntu I can set the
>> window title. E.g. by using the GUI menu (Terminal-> Set Title...),
>> or by setting it with a shell command, e.g. with something like
>>
>> echo -ne "\033]0;SOME TITLE HERE\007"
>>
>> Is there an equally simple way to _interrogate_ the window title by
>> a shell command?
Thanks for all the suggestions in this thread!
> In article <s5la58$2ok$1...@news-1.m-online.net>,
> Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>> With the standard shell terminal that I use on Ubuntu I can set the
>> window title. E.g. by using the GUI menu (Terminal-> Set Title...),
>> or by setting it with a shell command, e.g. with something like
>>
>> echo -ne "\033]0;SOME TITLE HERE\007"
>>
>> 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.
StackExchange link :-) this 'xdotool' option might be the fitting one.
My intention is to call it from the shell exit trap; I suppose at that
stage the embedding window is (still) considered being the active one.
I'll try incorporating that tool. Thanks!
>
> In fact, it is kind of a weakness in xdotool, that there is no obvious way
> to get information about the calling process's window; using
> getactivewindow is a kludge, but it is likely to work in most cases.
>
> Thinking about this some more, I suppose what you could do is:
>
> # At the beginning...
> echo -ne "\033]0;SOME TITLE HERE\007"
> myWinId=$(xdotool search --only --sync --name "SOME TITLE HERE")
is not guaranteed that the title is set by command line. It could also
be set by the GUI menu and should then also be retrievable.
The 'xdotool' suggestion makes that requirement possible.
(If I'd set the title per script then I wouldn't need to interrogate
it in my application case (see below) because then I'd just store it
for later retrieval in a dot-file, performed by the settitle-script.)
>
> # Then later on...
> # set it to whatever you really want it to...
> echo -ne "\033]0;whatever whatever probably dynamic\007"
>
> # Then later on...
> echo "My window title is: $(xdotool getwindowname $myWinId)"
I have the habit to open an own shell window for every (let's call it)
"task domain", and that may easily result in 20-60 shell instances.
Such "task domains" may handle topics like "Webpage generation and
publishing", "Image processing", "System programming", "Scripting
tests", "Book translation", "Doing statistics", "Playing roguelikes",
etc. Every domain shall have its own command history (not polluting
the other domain's shells), and it shall also memorize the working
directory (to have the commands from the history work properly) and
window title (to quickly find the right window in the set of minimized
windows) persistently in case of reboots (or crashes). Distinguished
by the tty/pts number I maintain a couple of dot files (.sh_history_#,
.sh_pwdstat_#, .sh_title_#) to restore that information when the shell
instances are opened anew.
Janis
Ben Bacarisse
Apr 20, 2021, 9:12:05 AM4/20/21
to
<cut>
often used when I want a script to run autonomously. I'll run it, then
go do something else which will, most likely, cause another window to
become active.
If this might be an issue, you should consider using getactivewindow at
the very start (as early as possible) and using the window number later
on to get the title:
win=$(xdotool getwindowname)
...
xdotool getwindowname $win
Of course, if the title does not change, you can just grab the title
early on instead.
--
Ben.
>> xdotool getactivewindow getwindowname
>>
>> should do it (at least as long as the calling window is the active window.
>
> Still frightened from the voluminous code behind the elsethread posted
> StackExchange link :-) this 'xdotool' option might be the fitting one.
> My intention is to call it from the shell exit trap; I suppose at that
> stage the embedding window is (still) considered being the active one.
You might have a problem there. In my typical scripts, an exit trap is
>>
>> should do it (at least as long as the calling window is the active window.
>
> Still frightened from the voluminous code behind the elsethread posted
> StackExchange link :-) this 'xdotool' option might be the fitting one.
> My intention is to call it from the shell exit trap; I suppose at that
> stage the embedding window is (still) considered being the active one.
often used when I want a script to run autonomously. I'll run it, then
go do something else which will, most likely, cause another window to
become active.
If this might be an issue, you should consider using getactivewindow at
the very start (as early as possible) and using the window number later
on to get the title:
win=$(xdotool getwindowname)
...
xdotool getwindowname $win
Of course, if the title does not change, you can just grab the title
early on instead.
--
Ben.
hongy...@gmail.com
Apr 20, 2021, 9:18:01 AM4/20/21
to
I'm not sure whether some alternative tools, like tmux can meet your requirements.
HY
> Janis
Spiros Bousbouras
Apr 20, 2021, 9:30:49 AM4/20/21
to
On Tue, 20 Apr 2021 13:08:27 +0200
Janis Papanagnou <janis_pa...@hotmail.com> wrote:
> On 20.04.2021 07:18, Kenny McCormack wrote:
> > In article <s5la58$2ok$1...@news-1.m-online.net>,
> > Janis Papanagnou <janis_pa...@hotmail.com> wrote:
> >> With the standard shell terminal that I use on Ubuntu I can set the
> >> window title. E.g. by using the GUI menu (Terminal-> Set Title...),
> >> or by setting it with a shell command, e.g. with something like
> >>
> >> echo -ne "\033]0;SOME TITLE HERE\007"
> >>
> >> Is there an equally simple way to _interrogate_ the window title by
> >> a shell command?
I haven't used Gnome in many years. When I did , there was a gnome-terminal
Janis Papanagnou <janis_pa...@hotmail.com> wrote:
> On 20.04.2021 07:18, Kenny McCormack wrote:
> > In article <s5la58$2ok$1...@news-1.m-online.net>,
> > Janis Papanagnou <janis_pa...@hotmail.com> wrote:
> >> With the standard shell terminal that I use on Ubuntu I can set the
> >> window title. E.g. by using the GUI menu (Terminal-> Set Title...),
> >> or by setting it with a shell command, e.g. with something like
> >>
> >> echo -ne "\033]0;SOME TITLE HERE\007"
> >>
> >> Is there an equally simple way to _interrogate_ the window title by
> >> a shell command?
application. Is this what you mean by "standard shell terminal" ? The term
"standard shell terminal" itself is unclear. There may be a standard Gnome
terminal emulator (gnome-terminal ?) and it may be that the default behaviour
when you start it is to run a shell but the two are unrelated. Generally
terminal emulators have a command line option (for example -e in xterm) to
launch a different executable instead of a shell. Note also that your window
manager may be scriptable and may allow you to get a list of all the windows.
For example ratpoison offers this capability :
ratpoison -c windows
.You can also specify in what format you want the output.
[...]
> > Thinking about this some more, I suppose what you could do is:
> >
> > # At the beginning...
> > echo -ne "\033]0;SOME TITLE HERE\007"
> > myWinId=$(xdotool search --only --sync --name "SOME TITLE HERE")
>
> The problem with this (and also with Richard's suggestion) is that it
> is not guaranteed that the title is set by command line. It could also
> be set by the GUI menu and should then also be retrievable.
then surely you should have an automated way of doing it instead of doing it
by hand.
> The 'xdotool' suggestion makes that requirement possible.
>
> (If I'd set the title per script then I wouldn't need to interrogate
> it in my application case (see below) because then I'd just store it
> for later retrieval in a dot-file, performed by the settitle-script.)
>
> >
> > # Then later on...
> > # set it to whatever you really want it to...
> > echo -ne "\033]0;whatever whatever probably dynamic\007"
> >
> > # Then later on...
> > echo "My window title is: $(xdotool getwindowname $myWinId)"
>
> I should probably explain the application context...
>
> I have the habit to open an own shell window for every (let's call it)
> "task domain", and that may easily result in 20-60 shell instances.
> Such "task domains" may handle topics like "Webpage generation and
> publishing", "Image processing", "System programming", "Scripting
> tests", "Book translation", "Doing statistics", "Playing roguelikes",
> etc. Every domain shall have its own command history (not polluting
> the other domain's shells), and it shall also memorize the working
> directory (to have the commands from the history work properly) and
> window title (to quickly find the right window in the set of minimized
> windows) persistently in case of reboots (or crashes). Distinguished
> by the tty/pts number I maintain a couple of dot files (.sh_history_#,
> .sh_pwdstat_#, .sh_title_#) to restore that information when the shell
> instances are opened anew.
choice. If you open a shell for say "System programming" , you terminate it
and then open a new shell for the same purpose , don't you want the history
of the 2nd shell to be eventually appended to the history created by the
earlier shell for "System programming" ? In other words , don't you want files
.sh_history_* , .sh_pwdstat_* , .sh_title_* to be per task domain rather than
per tty/pts number ?
Perhaps I'm misunderstanding what you're trying to do but personally I would
do something like this :
start_task_specific_shell () {
# Takes one argument which will be the name of the task
export TASK_NAME="$1"
export HISTFILE="$HOME/tasks/.sh_history_$1"
# Issue the command to start the terminal emulator with a window name of $1
# or something derived from $1 ; for example for xterm
xterm -title "$1" -e /path/to/your/shell
# You probably need to pass some option to the shell so that first it reads
# $HOME/tasks/.sh_pwdstat_$1 and changes to the directory stored in there.
}
This way each shell can interrogate the TASK_NAME environmental variable to
find out what actions it should do on termination and won't have a need to
learn the window title.
--
Put style over substance abuse.
Spiros Bousbouras
Apr 20, 2021, 10:10:35 AM4/20/21
to
On Tue, 20 Apr 2021 05:18:40 -0000 (UTC)
gaz...@shell.xmission.com (Kenny McCormack) wrote:
> xdotool getactivewindow getwindowname
>
> should do it (at least as long as the calling window is the active window.
>
> In fact, it is kind of a weakness in xdotool, that there is no obvious way
> to get information about the calling process's window; using
> getactivewindow is a kludge, but it is likely to work in most cases.
But xdotool does not open a window. Presumably you're thinking of a
gaz...@shell.xmission.com (Kenny McCormack) wrote:
> xdotool getactivewindow getwindowname
>
> should do it (at least as long as the calling window is the active window.
>
> In fact, it is kind of a weakness in xdotool, that there is no obvious way
> to get information about the calling process's window; using
> getactivewindow is a kludge, but it is likely to work in most cases.
scenario where a user types on a shell command line
xdotool ...
and the shell runs on top of a terminal emulator and "the calling process's
window" is the one the terminal emulator has opened. But this is just one of
many scenarios. So I don't know what you'd want xdotool to provide.
--
Is an unstable hallucination healthier than a consistent one?
"Seeing" by Greg Egan
Janis Papanagnou
Apr 20, 2021, 11:20:39 AM4/20/21
to
helps to support the above mentioned requirements. The shell-only
solution I implemented with little code works pretty well.
Janis
Grant Taylor
Apr 20, 2021, 11:25:48 AM4/20/21
to
On 4/20/21 4:07 AM, Richard Harnden wrote:
> If you set the title as part of PS1, then you can query that ... ?
That's only reliable while sitting at the prompt. (If even then.)
> If you set the title as part of PS1, then you can query that ... ?
All of my systems change the title to be the command as part of a
pre-command function. So reading $PS1 as part of the command, e.g. a
script, will return something other than the current window title.
--
Grant. . . .
unix || die
Janis Papanagnou
Apr 20, 2021, 12:03:03 PM4/20/21
to
On 20.04.2021 15:30, Spiros Bousbouras wrote:
> On Tue, 20 Apr 2021 13:08:27 +0200
> Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>> On 20.04.2021 07:18, Kenny McCormack wrote:
>>> In article <s5la58$2ok$1...@news-1.m-online.net>,
>>> Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>>>> With the standard shell terminal that I use on Ubuntu I can set the
>>>> window title. E.g. by using the GUI menu (Terminal-> Set Title...),
>>>> or by setting it with a shell command, e.g. with something like
>>>>
>>>> echo -ne "\033]0;SOME TITLE HERE\007"
>>>>
>>>> Is there an equally simple way to _interrogate_ the window title by
>>>> a shell command?
>
> I haven't used Gnome in many years. When I did , there was a gnome-terminal
> application. Is this what you mean by "standard shell terminal" ? The term
> "standard shell terminal" itself is unclear.
Sorry for having been unclear. It's the default thing that comes up
> On Tue, 20 Apr 2021 13:08:27 +0200
> Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>> On 20.04.2021 07:18, Kenny McCormack wrote:
>>> In article <s5la58$2ok$1...@news-1.m-online.net>,
>>> Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>>>> With the standard shell terminal that I use on Ubuntu I can set the
>>>> window title. E.g. by using the GUI menu (Terminal-> Set Title...),
>>>> or by setting it with a shell command, e.g. with something like
>>>>
>>>> echo -ne "\033]0;SOME TITLE HERE\007"
>>>>
>>>> Is there an equally simple way to _interrogate_ the window title by
>>>> a shell command?
>
> I haven't used Gnome in many years. When I did , there was a gnome-terminal
> application. Is this what you mean by "standard shell terminal" ? The term
> "standard shell terminal" itself is unclear.
when clicking "Terminal" in the context menu of the screen. It's just
a shell window with a menu, where the 'Help' section mentions that it
is a "GNOME terminal" and "A terminal emulator for the GNOME desktop".
> There may be a standard Gnome
> terminal emulator (gnome-terminal ?) and it may be that the default behaviour
> when you start it is to run a shell but the two are unrelated. Generally
> terminal emulators have a command line option (for example -e in xterm) to
I know that but that seems to not be what I'm looking for but something
completely different.
>
>>> Thinking about this some more, I suppose what you could do is:
>>>
>>> # At the beginning...
>>> echo -ne "\033]0;SOME TITLE HERE\007"
>>> myWinId=$(xdotool search --only --sync --name "SOME TITLE HERE")
>>
>> The problem with this (and also with Richard's suggestion) is that it
>> is not guaranteed that the title is set by command line. It could also
>> be set by the GUI menu and should then also be retrievable.
>
> If you typically open 20-60 shells (and I assume also terminal emulators)
> then surely you should have an automated way of doing it instead of doing it
> by hand.
There's no automatism for choosing an appropriate title. Setting the
title, OTOH, is scripted, as is (now) re-setting the title on restart.
>>
>> I have the habit to open an own shell window for every (let's call it)
>> "task domain", and that may easily result in 20-60 shell instances.
>> Such "task domains" may handle topics like "Webpage generation and
>> publishing", "Image processing", "System programming", "Scripting
>> tests", "Book translation", "Doing statistics", "Playing roguelikes",
>> etc. Every domain shall have its own command history (not polluting
>> the other domain's shells), and it shall also memorize the working
>> directory (to have the commands from the history work properly) and
>> window title (to quickly find the right window in the set of minimized
>> windows) persistently in case of reboots (or crashes). Distinguished
>> by the tty/pts number I maintain a couple of dot files (.sh_history_#,
>> .sh_pwdstat_#, .sh_title_#) to restore that information when the shell
>> instances are opened anew.
>
> I take it # refers to "tty/pts number".
> If yes , I find it a strange
> choice. If you open a shell for say "System programming" , you terminate it
> and then open a new shell for the same purpose , don't you want the history
> of the 2nd shell to be eventually appended to the history created by the
> earlier shell for "System programming" ? In other words , don't you want files
> .sh_history_* , .sh_pwdstat_* , .sh_title_* to be per task domain rather than
> per tty/pts number ?
characterized by doing the same sets of commands. "System programming"
might invoke 'vi', 'cc', 'grep', or 'dmesg', etc. The history file will
memorize these commands. Reopening that shell instance after restarting
the system will work on the same history file and append to it. The CWD
and title, OTOH, will contain the most recent current working directory
and window title, respectively.
If you mean that the files, say, ".sh_history_4", should rather better
be named ".sh_history_System programming", then you won't load that file
automatically, because a restarted /dev/pts/4 doesn't know what task it
is supposed for. I need some automatically generated key (like "4") to
associate the context sets (CWD, title, history). You could of course
do a mapping from "/dev/pts/4" to "System programming", but then you
have no advantage of a verbose file name instead of just using the key.
But I may have misunderstood your suggestion, so please feel free to
explain.
>
> Perhaps I'm misunderstanding what you're trying to do but personally I would
> do something like this :
>
> start_task_specific_shell () {
> # Takes one argument which will be the name of the task
(Or start a console shell in case of non-windowing low-level access.)
> export TASK_NAME="$1"
> export HISTFILE="$HOME/tasks/.sh_history_$1"
>
> # Issue the command to start the terminal emulator with a window name of $1
> # or something derived from $1 ; for example for xterm
>
> xterm -title "$1" -e /path/to/your/shell
>
> # You probably need to pass some option to the shell so that first it reads
> # $HOME/tasks/.sh_pwdstat_$1 and changes to the directory stored in there.
> }
>
> This way each shell can interrogate the TASK_NAME environmental variable to
> find out what actions it should do on termination and won't have a need to
> learn the window title.
you pass the "task domain" name as argument, it's easy to "interrogate"
that title, but that is the part where there's also another solution
('xdotool') available.
Is there probably just more than one way to skin a cat, or am I missing
something essential?
Janis
Janis Papanagnou
Apr 20, 2021, 12:17:59 PM4/20/21
to
On 20.04.2021 16:10, Spiros Bousbouras wrote:
> On Tue, 20 Apr 2021 05:18:40 -0000 (UTC)
> gaz...@shell.xmission.com (Kenny McCormack) wrote:
>> xdotool getactivewindow getwindowname
>>
>> should do it (at least as long as the calling window is the active window.
>>
>> In fact, it is kind of a weakness in xdotool, that there is no obvious way
>> to get information about the calling process's window; using
>> getactivewindow is a kludge, but it is likely to work in most cases.
>
> But xdotool does not open a window. Presumably you're thinking of a
> scenario where a user types on a shell command line
>
> xdotool ...
In my context it's planned to be used to create a dot-file entry with
> On Tue, 20 Apr 2021 05:18:40 -0000 (UTC)
> gaz...@shell.xmission.com (Kenny McCormack) wrote:
>> xdotool getactivewindow getwindowname
>>
>> should do it (at least as long as the calling window is the active window.
>>
>> In fact, it is kind of a weakness in xdotool, that there is no obvious way
>> to get information about the calling process's window; using
>> getactivewindow is a kludge, but it is likely to work in most cases.
>
> But xdotool does not open a window. Presumably you're thinking of a
> scenario where a user types on a shell command line
>
> xdotool ...
the title information.
$HOME/.kshrc:
TTY=$( tty )
TTYNR=${TTY##*[/]}
...
trap "xdotool getactivewindow getwindowname >
${HOME}/.sh_title_${TTYNR}" EXIT
...
# and here similarly recovery of title from that dot-file on startup
...
or if I want to set (and memorize) the title by script
TTY=$( tty )
TTYNR=${TTY##*[/]}
title=${@:-${TTY}}
printf "\e]0;%s \a" "${title}"
printf "%s\n" "${title}" > "${HOME}/.sh_title_${TTYNR}"
Janis
Grant Taylor
Apr 20, 2021, 1:17:50 PM4/20/21
to
On 4/20/21 10:17 AM, Janis Papanagnou wrote:
> In my context it's planned to be used to create a dot-file entry with
> the title information.
ProTip: Test your modification / functionality in multiple terminals
> In my context it's planned to be used to create a dot-file entry with
> the title information.
/and/ system (text / VGA / serial) console.
I've been bitten by some fancy things really messing up virtual console
prompts. Mostly in extra characters that GUI terminal emulators
consider non-printing showing up on the (...) console.
My workaround was to check the TERM variable and conditionally set such
features only in supported terminals. Thankfully XTerm and Linux
console use different TERM values by default.
Michael F. Stemper
Apr 20, 2021, 1:22:55 PM4/20/21
to
On 20/04/2021 05.07, Richard Harnden wrote:
> On 20/04/2021 02:18, Janis Papanagnou wrote:
>> With the standard shell terminal that I use on Ubuntu I can set the
>> window title. E.g. by using the GUI menu (Terminal-> Set Title...),
>> or by setting it with a shell command, e.g. with something like
>>
>> echo -ne "\033]0;SOME TITLE HERE\007"
>>
>> Is there an equally simple way to _interrogate_ the window title by
>> a shell command?
>>
>
> On 20/04/2021 02:18, Janis Papanagnou wrote:
>> With the standard shell terminal that I use on Ubuntu I can set the
>> window title. E.g. by using the GUI menu (Terminal-> Set Title...),
>> or by setting it with a shell command, e.g. with something like
>>
>> echo -ne "\033]0;SOME TITLE HERE\007"
>>
>> Is there an equally simple way to _interrogate_ the window title by
>> a shell command?
>>
>
> If you set the title as part of PS1, then you can query that ... ?
As long as you don't use any variables. For instance,
$ echo $PS1
\[\e]0;\u@\h: \w\a\]\u@\h$
$
I suppose that there is a definition for all of this that your program
could use for parsing it out, but that's likely to be error-prone.
--
Michael F. Stemper
Galatians 3:28
Spiros Bousbouras
Apr 20, 2021, 2:30:48 PM4/20/21
to
On Tue, 20 Apr 2021 18:17:55 +0200
Janis Papanagnou <janis_pa...@hotmail.com> wrote:
> In my context it's planned to be used to create a dot-file entry with
> the title information.
>
> $HOME/.kshrc:
>
> TTY=$( tty )
> TTYNR=${TTY##*[/]}
> ...
> trap "xdotool getactivewindow getwindowname >
> ${HOME}/.sh_title_${TTYNR}" EXIT
> ...
> # and here similarly recovery of title from that dot-file on startup
> ...
And how do you guarantee what the active window will be when the trap gets
Janis Papanagnou <janis_pa...@hotmail.com> wrote:
> In my context it's planned to be used to create a dot-file entry with
> the title information.
>
> $HOME/.kshrc:
>
> TTY=$( tty )
> TTYNR=${TTY##*[/]}
> ...
> trap "xdotool getactivewindow getwindowname >
> ${HOME}/.sh_title_${TTYNR}" EXIT
> ...
> # and here similarly recovery of title from that dot-file on startup
> ...
executed ? If for example your only scenario is that you type exit on
the shell command line then the active window will be the one the shell is
running on so that's ok. Are you sure this is the only scenario you're
interested in ?
Spiros Bousbouras
Apr 20, 2021, 2:50:58 PM4/20/21
to
On Tue, 20 Apr 2021 11:17:52 -0600
Grant Taylor <gta...@tnetconsulting.net> wrote:
> On 4/20/21 10:17 AM, Janis Papanagnou wrote:
> > In my context it's planned to be used to create a dot-file entry with
> > the title information.
>
> ProTip: Test your modification / functionality in multiple terminals
> /and/ system (text / VGA / serial) console.
If it's running on console I expect xdotool will exit with an error
Grant Taylor <gta...@tnetconsulting.net> wrote:
> On 4/20/21 10:17 AM, Janis Papanagnou wrote:
> > In my context it's planned to be used to create a dot-file entry with
> > the title information.
>
> ProTip: Test your modification / functionality in multiple terminals
> /and/ system (text / VGA / serial) console.
because the DISPLAY variable won't be set.
Spiros Bousbouras
Apr 20, 2021, 3:24:45 PM4/20/21
to
On Tue, 20 Apr 2021 18:02:58 +0200
> There's no automatism for choosing an appropriate title. Setting the
> title, OTOH, is scripted, as is (now) re-setting the title on restart.
I assumed that across different login sessions you have some common sets of
tasks like "System programming" , "Doing statistics" , etc. and that you want
a separate history per task domain and that you want the window title to
reflect the task domain the shell running on the window will be used for.
So if you open a new shell for doing "System programming" you want its
working directory to be the same as the working directory of the last shell
you used for "System programming" , yes ? Don't you also want the window
title to be "System programming" ?
> If you mean that the files, say, ".sh_history_4", should rather better
> be named ".sh_history_System programming", then you won't load that file
> automatically, because a restarted /dev/pts/4 doesn't know what task it
> is supposed for.
Which is why I suggested having the start_task_specific_shell function
below so that the pts number becomes irrelevant. So lets say that during a
login session you have a few shells open but you haven't done any "System
programming" yet. At some point you decide that you want to do some so you
open a new terminal emulator. This will (I think) get the first pts number
available , lets say 4. So the shell will load .sh_history_4 .But it could
be that during your previous login session you used the shell on /dev/pts/4
for "Doing statistics" so now , instead of loading the history with the
commands from the last time you did "System programming" , the shell you just
started will get the history with the commands from the last time you did
"Doing statistics". Whereas with the scheme I proposed , you just type on an
already open shell (I'm guessing you could also configure Gnome to do it by
clicking on an icon or something and launch a dialogue)
start_task_specific_shell "System programming"
.The shell will load ".sh_history_System programming" and which pts number
it gets doesn't matter.
> I need some automatically generated key (like "4") to
> associate the context sets (CWD, title, history). You could of course
> do a mapping from "/dev/pts/4" to "System programming", but then you
> have no advantage of a verbose file name instead of just using the key.
>
> But I may have misunderstood your suggestion, so please feel free to
> explain.
I hope I did.
> > Perhaps I'm misunderstanding what you're trying to do but personally I would
> > do something like this :
> >
> > start_task_specific_shell () {
> > # Takes one argument which will be the name of the task
>
> I start a shell window (without arguments) using the GUI context menu.
> (Or start a console shell in case of non-windowing low-level access.)
I don't think xdotool will print anything useful running on Linux console.
> > export TASK_NAME="$1"
> > export HISTFILE="$HOME/tasks/.sh_history_$1"
>
> And things like these are done im my $HOME/.kshrc file.
>
> >
> > # Issue the command to start the terminal emulator with a window name of $1
> > # or something derived from $1 ; for example for xterm
> >
> > xterm -title "$1" -e /path/to/your/shell
> >
> > # You probably need to pass some option to the shell so that first it reads
> > # $HOME/tasks/.sh_pwdstat_$1 and changes to the directory stored in there.
> > }
> >
> > This way each shell can interrogate the TASK_NAME environmental variable to
> > find out what actions it should do on termination and won't have a need to
> > learn the window title.
>
> Frankly, I see no advantage doing it that way. As I understand it, since
> you pass the "task domain" name as argument, it's easy to "interrogate"
> that title, but that is the part where there's also another solution
> ('xdotool') available.
>
> Is there probably just more than one way to skin a cat, or am I missing
> something essential?
--
I am writing this mail to you with serious tears in my eyes and great
sorrow in my heart
An email offering me 30% of $7,200,200
Janis Papanagnou <janis_pa...@hotmail.com> wrote:
> On 20.04.2021 15:30, Spiros Bousbouras wrote:
> > On Tue, 20 Apr 2021 13:08:27 +0200
> > Janis Papanagnou <janis_pa...@hotmail.com> wrote:
> >
> > If you typically open 20-60 shells (and I assume also terminal emulators)
> > then surely you should have an automated way of doing it instead of doing it
> > by hand.
>
> What do you mean by "it"?
I mean opening 20-60 shells.
> On 20.04.2021 15:30, Spiros Bousbouras wrote:
> > On Tue, 20 Apr 2021 13:08:27 +0200
> > Janis Papanagnou <janis_pa...@hotmail.com> wrote:
> >
> > If you typically open 20-60 shells (and I assume also terminal emulators)
> > then surely you should have an automated way of doing it instead of doing it
> > by hand.
>
> What do you mean by "it"?
> There's no automatism for choosing an appropriate title. Setting the
> title, OTOH, is scripted, as is (now) re-setting the title on restart.
tasks like "System programming" , "Doing statistics" , etc. and that you want
a separate history per task domain and that you want the window title to
reflect the task domain the shell running on the window will be used for.
working directory to be the same as the working directory of the last shell
you used for "System programming" , yes ? Don't you also want the window
title to be "System programming" ?
> If you mean that the files, say, ".sh_history_4", should rather better
> be named ".sh_history_System programming", then you won't load that file
> automatically, because a restarted /dev/pts/4 doesn't know what task it
> is supposed for.
below so that the pts number becomes irrelevant. So lets say that during a
login session you have a few shells open but you haven't done any "System
programming" yet. At some point you decide that you want to do some so you
open a new terminal emulator. This will (I think) get the first pts number
available , lets say 4. So the shell will load .sh_history_4 .But it could
be that during your previous login session you used the shell on /dev/pts/4
for "Doing statistics" so now , instead of loading the history with the
commands from the last time you did "System programming" , the shell you just
started will get the history with the commands from the last time you did
"Doing statistics". Whereas with the scheme I proposed , you just type on an
already open shell (I'm guessing you could also configure Gnome to do it by
clicking on an icon or something and launch a dialogue)
start_task_specific_shell "System programming"
.The shell will load ".sh_history_System programming" and which pts number
it gets doesn't matter.
> I need some automatically generated key (like "4") to
> associate the context sets (CWD, title, history). You could of course
> do a mapping from "/dev/pts/4" to "System programming", but then you
> have no advantage of a verbose file name instead of just using the key.
>
> But I may have misunderstood your suggestion, so please feel free to
> explain.
> > Perhaps I'm misunderstanding what you're trying to do but personally I would
> > do something like this :
> >
> > start_task_specific_shell () {
> > # Takes one argument which will be the name of the task
>
> I start a shell window (without arguments) using the GUI context menu.
> (Or start a console shell in case of non-windowing low-level access.)
> > export TASK_NAME="$1"
> > export HISTFILE="$HOME/tasks/.sh_history_$1"
>
> And things like these are done im my $HOME/.kshrc file.
>
> >
> > # Issue the command to start the terminal emulator with a window name of $1
> > # or something derived from $1 ; for example for xterm
> >
> > xterm -title "$1" -e /path/to/your/shell
> >
> > # You probably need to pass some option to the shell so that first it reads
> > # $HOME/tasks/.sh_pwdstat_$1 and changes to the directory stored in there.
> > }
> >
> > This way each shell can interrogate the TASK_NAME environmental variable to
> > find out what actions it should do on termination and won't have a need to
> > learn the window title.
>
> Frankly, I see no advantage doing it that way. As I understand it, since
> you pass the "task domain" name as argument, it's easy to "interrogate"
> that title, but that is the part where there's also another solution
> ('xdotool') available.
>
> Is there probably just more than one way to skin a cat, or am I missing
> something essential?
I am writing this mail to you with serious tears in my eyes and great
sorrow in my heart
An email offering me 30% of $7,200,200
Grant Taylor
Apr 20, 2021, 3:49:01 PM4/20/21
to
On 4/20/21 12:50 PM, Spiros Bousbouras wrote:
> If it's running on console I expect xdotool will exit with an error
> because the DISPLAY variable won't be set.
Maybe. Maybe not. As in it's entirely possible to set and export the
> If it's running on console I expect xdotool will exit with an error
> because the DISPLAY variable won't be set.
DISPLAY variable while logged into a VGA / serial console. I've done it
multiple times.
Admittedly, it's not likely. But it is decidedly possible.
Either way, the OP still needs to be mindful of how the script behaves
in GUI terminal emulators vs how it might fail in VGA / serial console.
/If/ xdotool fails gracefully, great. Does that mean that the rest of
the logic around xdotool also fails gracefully? Questions. Questions. ;-)
Hence the ProTip to test and know vs not testing and hoping.
Janis Papanagnou
Apr 21, 2021, 6:27:52 AM4/21/21
to
On 20.04.2021 21:49, Grant Taylor wrote:
>
> Hence the ProTip to test and know vs not testing and hoping.
Agreed. Luckily it's just a local configuration, so there's
>
> Hence the ProTip to test and know vs not testing and hoping.
not too many (or even unknown) cases need consideration.
Janis
Janis Papanagnou
Apr 21, 2021, 6:51:12 AM4/21/21
to
On 20.04.2021 20:30, Spiros Bousbouras wrote:
> On Tue, 20 Apr 2021 18:17:55 +0200
> Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>> In my context it's planned to be used to create a dot-file entry with
>> the title information.
>>
>> $HOME/.kshrc:
>>
>> TTY=$( tty )
>> TTYNR=${TTY##*[/]}
>> ...
>> trap "xdotool getactivewindow getwindowname >
>> ${HOME}/.sh_title_${TTYNR}" EXIT
>> ...
>> # and here similarly recovery of title from that dot-file on startup
>> ...
>
> And how do you guarantee what the active window will be when the trap gets
> executed ?
That's an inherent problem that I see and also thought about. The short
> On Tue, 20 Apr 2021 18:17:55 +0200
> Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>> In my context it's planned to be used to create a dot-file entry with
>> the title information.
>>
>> $HOME/.kshrc:
>>
>> TTY=$( tty )
>> TTYNR=${TTY##*[/]}
>> ...
>> trap "xdotool getactivewindow getwindowname >
>> ${HOME}/.sh_title_${TTYNR}" EXIT
>> ...
>> # and here similarly recovery of title from that dot-file on startup
>> ...
>
> And how do you guarantee what the active window will be when the trap gets
> executed ?
answer is that I actually cannot guarantee it.
> If for example your only scenario is that you type exit on
> the shell command line then the active window will be the one the shell is
> running on so that's ok.
> Are you sure this is the only scenario you're interested in ?
this approach; if the system freezes or crashes and I have to do a hard
reboot. But even in that case the effects are non-critical; the title is
just lost and has to be redefined manually. In case that I use a script
(like the one quoted below) there's no issue at all.
Janis
Janis Papanagnou
Apr 21, 2021, 7:48:25 AM4/21/21
to
On 20.04.2021 21:24, Spiros Bousbouras wrote:
> On Tue, 20 Apr 2021 18:02:58 +0200
> Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>> On 20.04.2021 15:30, Spiros Bousbouras wrote:
>>> On Tue, 20 Apr 2021 13:08:27 +0200
>>> Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>
>> There's no automatism for choosing an appropriate title. Setting the
>> title, OTOH, is scripted, as is (now) re-setting the title on restart.
>
> I assumed that across different login sessions you have some common sets of
> tasks like "System programming" , "Doing statistics" , etc. and that you want
> a separate history per task domain and that you want the window title to
> reflect the task domain the shell running on the window will be used for.
Right. Most task domains are static in the sense that they are
> On Tue, 20 Apr 2021 18:02:58 +0200
> Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>> On 20.04.2021 15:30, Spiros Bousbouras wrote:
>>> On Tue, 20 Apr 2021 13:08:27 +0200
>>> Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>
>> There's no automatism for choosing an appropriate title. Setting the
>> title, OTOH, is scripted, as is (now) re-setting the title on restart.
>
> I assumed that across different login sessions you have some common sets of
> tasks like "System programming" , "Doing statistics" , etc. and that you want
> a separate history per task domain and that you want the window title to
> reflect the task domain the shell running on the window will be used for.
regularly or repeatedly used with different pause intervals in
Real Life.
>
> So if you open a new shell for doing "System programming" you want its
> working directory to be the same as the working directory of the last shell
> you used for "System programming" , yes ? Don't you also want the window
> title to be "System programming" ?
or related to such names. (In the context of my text below I
provide an example.)
>
>> If you mean that the files, say, ".sh_history_4", should rather better
>> be named ".sh_history_System programming", then you won't load that file
>> automatically, because a restarted /dev/pts/4 doesn't know what task it
>> is supposed for.
>
> Which is why I suggested having the start_task_specific_shell function
> below so that the pts number becomes irrelevant. So lets say that during a
> login session you have a few shells open but you haven't done any "System
> programming" yet. At some point you decide that you want to do some so you
> open a new terminal emulator. This will (I think) get the first pts number
> available , lets say 4. So the shell will load .sh_history_4 .But it could
> be that during your previous login session you used the shell on /dev/pts/4
> for "Doing statistics" so now , instead of loading the history with the
> commands from the last time you did "System programming" , the shell you just
> started will get the history with the commands from the last time you did
> "Doing statistics". Whereas with the scheme I proposed , you just type on an
> already open shell (I'm guessing you could also configure Gnome to do it by
> clicking on an icon or something and launch a dialogue)
>
> start_task_specific_shell "System programming"
>
> .The shell will load ".sh_history_System programming" and which pts number
> it gets doesn't matter.
desirable behavior. Let's consider the two cases.
"System programming", "System Programming", "System programing",
"System-programming", etc. etc. - it needs accurate spelling or
you'll get a new domain context. (Of course you can address that
by additional means like predefined tables with domain context
names, or a list of GUI entries to select from, etc. - but that
is an issue.) And I also have to type a lot of text to create a
shell from a console. Either way I find that to be inconvenient.
In the other case I just open a shell terminal and it gets the
next available pts number assigned automatically. Since there's
a standard set of task domains (as described above) the first
couple opened terminals serve my purpose. The history, working
directory, and title, are automatically assigned (I don't need
to know the number, or the title). A click and everything is
there. The fact that, say, 5 of the 20 terminals are unused is
unimportant; they are hidden in the task-bar and quickly opened
when necessary, identified by their title, and predefined with
their specific context.
(It may be worthwhile to mention that I don't start my machine
two times a day, it's rather constantly running. So valuation
of the available options may vary depending on reboot frequency
and how many shell terminal windows folks have open.)
The choice of the methods may also be influenced by how constant
the titles are. As said, there are a couple of fixed domains.
Others may change; for example the development tasks windows
may get specified more accurately, say (example from my current
environment), change from "Development" and "Test" to "Codenames
Server" and "Codenames Client". This is important to distinguish
by title, but the development context is basically the same, and
the component names (like "Codenames") may change.
>>
>> But I may have misunderstood your suggestion, so please feel free to
>> explain.
>
> I hope I did.
Janis
Friedhelm Waitzmann
Apr 28, 2021, 1:36:41 PM4/28/21
to
Janis Papanagnou:
>ENVIRONMENT
> Xterm sets several environment variables.
>
> System Independent
> Some variables are used on every system:
>
[…]
> WINDOWID
> is set to the X window id number of the xterm
> window.
If I remember right, this window ID is represented as a string of
decimal digits. Perhaps the gnome-terminal program does the same.
Friedhelm
>On 20.04.2021 20:30, Spiros Bousbouras wrote:
>>
>> And how do you guarantee what the active window will be when
>> the trap gets executed ?
>That's an inherent problem that I see and also thought about. The short
>answer is that I actually cannot guarantee it.
From the manual page xterm(1):
>>
>> And how do you guarantee what the active window will be when
>> the trap gets executed ?
>That's an inherent problem that I see and also thought about. The short
>answer is that I actually cannot guarantee it.
>ENVIRONMENT
> Xterm sets several environment variables.
>
> System Independent
> Some variables are used on every system:
>
[…]
> WINDOWID
> is set to the X window id number of the xterm
> window.
If I remember right, this window ID is represented as a string of
decimal digits. Perhaps the gnome-terminal program does the same.
Friedhelm
Kenny McCormack
Apr 28, 2021, 3:13:07 PM4/28/21
to
In article <s6c6f1$plb$1...@gioia.aioe.org>,
Friedhelm Waitzmann <usenet20...@spamgourmet.com> wrote:
...
But, yeah, xterm does.
As I said earlier, this is an inherent limitation in using xdotool. There's
no really good way to get "my" window ID. There are various kludges, and,
eventually, you will find a kludge that you are comfortable with.
--
Trump has normalized hate.
The media has normalized Trump.
Friedhelm Waitzmann <usenet20...@spamgourmet.com> wrote:
...
>> WINDOWID
>> is set to the X window id number of the xterm
>> window.
>
>If I remember right, this window ID is represented as a string of
>decimal digits. Perhaps the gnome-terminal program does the same.
It doesn't. I just checked on my Ubuntu/Gnome system.
>> is set to the X window id number of the xterm
>> window.
>
>If I remember right, this window ID is represented as a string of
>decimal digits. Perhaps the gnome-terminal program does the same.
But, yeah, xterm does.
As I said earlier, this is an inherent limitation in using xdotool. There's
no really good way to get "my" window ID. There are various kludges, and,
eventually, you will find a kludge that you are comfortable with.
--
Trump has normalized hate.
The media has normalized Trump.
Janis Papanagnou
Apr 30, 2021, 10:11:48 PM4/30/21
to
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_pa...@hotmail.com> wrote:
>>>
>>> Is there an equally simple way to _interrogate_ the window title by
>>> a shell command?
>>
> On 20.04.2021 07:18, Kenny McCormack wrote:
>> In article <s5la58$2ok$1...@news-1.m-online.net>,
>> Janis Papanagnou <janis_pa...@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.
>
>>
>> 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}"
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
Spiros Bousbouras
May 1, 2021, 3:19:54 AM5/1/21
to
On Sat, 1 May 2021 04:11:44 +0200
Janis Papanagnou <janis_pa...@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
Janis Papanagnou <janis_pa...@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)
"${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 works fine is a plain shell instance nesting, ksh->ksh->ksh.)
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}"
Janis Papanagnou
May 1, 2021, 3:47:55 AM5/1/21
to
On 01.05.2021 09:19, Spiros Bousbouras wrote:
> On Sat, 1 May 2021 04:11:44 +0200
> Janis Papanagnou <janis_pa...@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.)
> On Sat, 1 May 2021 04:11:44 +0200
> Janis Papanagnou <janis_pa...@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 ?
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}"
>
> ?
using the '!cmd' mechanism, or to create an executable shebang file
and call that from within the tools? (I'll try the latter.)
Janis
Spiros Bousbouras
May 1, 2021, 3:58:45 AM5/1/21
to
On Sat, 1 May 2021 09:47:51 +0200
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 .
Janis Papanagnou <janis_pa...@hotmail.com> wrote:
> On 01.05.2021 09:19, Spiros Bousbouras wrote:
> > On Sat, 1 May 2021 04:11:44 +0200
> > Janis Papanagnou <janis_pa...@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
> On 01.05.2021 09:19, Spiros Bousbouras wrote:
> > On Sat, 1 May 2021 04:11:44 +0200
> > Janis Papanagnou <janis_pa...@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).
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.)
#!/usr/bin/ksh
xdotool getactivewindow getwindowname >"${HOME}/.sh_title_${TTYNR}"
Janis Papanagnou
May 1, 2021, 6:18:37 AM5/1/21
to
> 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 ? [...]
>> On Sat, 1 May 2021 04:11:44 +0200
>>
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
Janis Papanagnou
May 2, 2021, 6:03:59 AM5/2/21
to
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
> 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}"
>
> ?
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
0 new messages